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Description 

[0001 ] A portion of the disclosure of this patent document contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent 
5 disclosure, as it appears in the Patent and Trademaric Office patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

Background of the Invention 

w [0002] This invention relates in general to the field of programming, and more particularly to using a high level pro- 
gramming language with a smart card or a microcontroller 

[0003] Software applications written In the Java high-level programming language have been so designed that an 
application written in Java can be run on many different computer brands or computer platfonns without change. This 
is accomplished by the following procedure. When a Java application is written, It is compiled into "Class" files containing 
15 byte codes that are Instructions for a hypothetical computer called a Java Virtual (Machine. An Implementation of this 
virtual machine is written for each platfomri that is supported. When a user wishes to run a particular Java application 
on a selected platform, the class files compiled from the desired application is loaded onto the selected platform. The 
Java virtual machine for the selected platfonn is run, and interprets the byte codes in the class file, thus effectively 
running the Java application. 

20 [0004] Java is described in the following references which are hereby incorporated by reference: (1) Arnold, Ken, 
and James Gosling, The Java Programming Language," Addison-Wesley, 1 996; (2) James Gosling, Bill Joy, and Guy 
Steele, "The Java Language Specification," Sun Microsystems, 1996, (web site: http://lava.sun.com/doc/ 
language_specification); (3) James Gosling and Henry McGilton, "The Java Language Environment: A White Paper," 
Sun Microsystems, 1995 (web site: http://java.sun.com/doc/language_environment/); and (4) Tim Lindholm and Frank 

25 Yellin, "The Java Virtual Machine Specification," Addison-Wesley, 1 997. These texts among many others describe how 
to program using Java. 

[0005] In order for a Java application to run on a specific platform, a Java virtual machine implementation must be 
written that will run within the constraints of the platform, and a mechanism must be provided for loading the desired 
Java application on the platform, again keeping within the constraints of this platform. 
30 [0006] Conventional platforms that support Java are typically microprocessor-based computers, with access to rel- 
atively large amounts of memory and hard disk storage space. Such microprocessor implementations frequently are 
used in desktop and personal computers. However, there are no conventional Java implementations on microcontrol- 
lers, as would typically be used in a smart card. 

[0007] Microcontrollers differ from microprocessors in many ways. For example, a microprocessor typically has a 
35 central processing unit that requires certain extemal components (e.g., memory, input controls and output controls) to 
function property. A typical microprocessor can access from a megabyte to a gigabyte of memory, and is capable of 
processing 16, 32, or 64 bits of Information or more with a single instruction. In contrast to the mtoroprocessor, a 
microcontroller includes a central processing unit, memory and other functional elements, all on a single semiconductor 
substrate, or integrated circuit (e.g., a "chip"). As compared to the relatively large external memory accessed by the 
40 microprocessor, the typical microcontroller accesses a much smaller memory. A typical microcontroller can access 
one to sixty-four kilobytes of built-in memory, with sixteen kilobytes being very common. 

[0008] There are generally three different types of memory used: random access memory (RAM), read only memory 
(ROM), and electrically erasable programmable read only memory (EEPROM). In a microcontroller, the amount of 
each kind of memory available is constrained by the amount of space on the integrated circuit used for each kind of 
45 memory. Typically, RAM takes the most space, and is in shortest supply. ROM takes the least space, and is abundant. 
EEPROM is more abundant than RAM, but less than ROM. 

[0009] Each kind of memory is suitable for different purposes. Although ROM is the least expensive, it Is suitable 
only for data that is unchanging, such as operating system code. EEPROM is useful for storing data that must be 
retained when power is removed, but is extremely slow to write. RAM can be written and read at high speed, but is 

so expensive and data in RAM is lost when power is removed. 

A microprocessor system typrcally has relatively little ROM and EEPROM, and has 1 to 128 megabytes of I^M, since 
it Is not constrained by what will fit on a single integrated circuit device, and often has access to an external disk memory 
system that serves as a large writable, non-volatile storage area at a lower cost than EEPROM. However, a microcon- 
troller typically has a small RAM of 0.1 to 2.0 K, 2K to 8K of EEPROM, and 8K - 56K of ROM. 

55 [0010] Due to the small number of external components required and their small size, microcontrollers frequently 
are used in integrated circuit cards, such as smart cards. Such smart cards come in a variety of forms, including contact- 
based cards, which must be inserted into a reader to be used, and contactless cards, which need not be inserted. In 
fact, microcontrollers with contactless communication are often embedded into specialized forms, such as watches 
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and rings, effectively integrating the functionality of a smart card in an ergononnically attractive nnanner. 
[001 1 ] Because of the constrained environment, applications for smart cards are typically written in a low level pro- 
gramming language (e.g., assembly language) to conserve memory. 

[0012] One way to program smart cards using a high level programming language is described In French patent 
5 application no. 90 1 1 8 1 8, entitied "Portable support medium for an easily programmable mlcrocircuit and programming 
procedure for said microcircuit", publication no. 2.667,171. IHowever, that patent application does not address data 
security concerns, describe how to prevent unauthorized access of the data and information on the smart card, nor 
how to provide a programming environment that would enable a programmer to create a program for a smart card in 
a rich programming language such as JAVA and yet execute the program using an interpreter on the smart card that 
10 operates within the execution constraints of the smart card. 

[0013] The integrated circuit card is a secure, robust, tamper-resistant and portable device for storing data. The 
integrated circuit card is the most personal of personal computers because of its small size and because of the hardware 
and software data security features unique to the Integrated circuit card. 

[0014] The primary task of the integrated circuit card and the microcontroller on the card is to protect the data stored 
15 on the card. Consequently, since its invention in 1 974, integrated circuit card technology has been closely guarded on 
these same security grounds. The cards were first used by French banks as debit cards. In this application, before a 
financial transaction based on the card is authorized, the card user must demonstrate knowledge of a 4-digit personal 
identification number (PIN) stored in the card in addition to being In possession of the card. Any information that might 
contribute to discovering the PIN number on a lost or stolen card was blocked from public distribution. In fact, since 
20 nobody could tell what infonrtation might be useful in this regard, virtually all infomnation about Integrated circuit cards 
was withheld. 

[0015] Due to the concern for security, applications written for integrated circuit cards have unique properties. For 
example, each application typically is identified with a particular owner or Identity. Because applications typically are 
written In a low-level programming language, such as assembly language, the applications are written for a particular 
25 type of microcontroller. Due to the nature of low level progrannming languages, unauthorized applications may access 
data on the Integrated circuit card. Programs written for an integrated circuit card are identified with a particular identity 
so that if two identities want to perfonn the same programming function there must be two copies of some portions of 
the application cn the microcontroller of the integrated circuit card. 

[0016] Integrated circuit card systems have historically been closed systems. An Integrated circuit card contained a 
30 dedicated applk:ation that was handcrafted to work with a specific terminal application. Security checking when an 
integrated circuit card was used consisted primarily of making sure that the card application and the temninal application 
were a matched pair and that the data on the card was valid. 

[0017] As the popularity of integrated circuit cards grew. It became clear that Integrated circuit card users would be 
averse to carrying a different Integrated circuit card for each integrated circuit card application. Therefore, multiple 
35 cooperating applications began to be provided on single provider integrated circuit cards. Thus, for example, an auto- 
mated teller machine (ATM) access card and a debit card may coexist on a single integrated circuit card platfomn. 
Nevertheless, this was still a closed system since all the applications in the terminal and the card were built by one 
provider having explicit knowledge of the other providers. 

[0018] The paucity of Infomnation about integrated circuit cards - particularly infonrtation about how to communicate 
40 with them and how to program them has impeded the general application of the integrated circuit card. However, 
the advent of public digital networking (e.g., the Internet and the Worid Wide Web) has opened new domains of appli- 
cation for integrated circuit cards. In particular, this has lead to a need to load new applications on the card that do not 
have explicit knowledge of the other providers, but without the possibility of compromising the security of the card. 
However, typically, this Is not practical with conventional cards that are programmed using low level languages. 

45 

Summary of the Invention 

[001 9] In general, in one aspect, the invention features an Integrated circuit card for use with a temninal. The integrated 
circuit card includes a memory that stores an interpreter and an application that has a high level programming language 
50 format. A processor of the card is configured to use the interpreter to interpret the application for execution and to use 

a communicator of the card to communicate with the temninal. 

[0020] Among the advantages of the invention are one or more of the following. New applications may be downloaded 
to a smart card without compromising the security of the smart card. These applications may be provided by different 
companies loaded at different times using different tenminals. Security is not compromised since the applications are 
55 protected against unauthorized access of any application code or data by the security features provided by the Java 
virtual machine. Smart card applications can be created in high level languages such as Java and Eiffel, using powerful 
mainstream program development tools. New applications can be quickly prototyped and downloaded to a smart card 
In a matter of hours without resorting to soft masks. Embedded systems using microcontrollers can also gain many of 
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these advantages for downloading new applications, high level progrann developntent, and rapid prototyping by making 

use of this invention. 

[0021] Implementations of the invention may include one or more of the following. The high level programming lan- 
guage format of the application may have a class file fomnat and may have a Java programming language fonnat. The 

5 processor may be a microcontrolter. At least a portion of the memory may be located In the processor. 

[0022] The application may have been processed from a second application that has a string of characters, and the 
string of characters may be represented in the first application by an identifier (e.g., an integer). 
[0023] The processor may be also configured to receive a request from a requester (e.g., a processor or a terminal) 
to access an element (e.g., an application stored in the memory, data stored in the memory or the communicator) of 

10 the card, after receipt of the request, interact with the requester to authenticate an identity of the requester, and based 
on the identity, selectively grant access to the element. 

[0024] The memory may also store an access control list for the element. The access control list furnishes an indi- 
cation of types of access to be granted to the identity, and based on the access control list, the processor selectively 
grants specific types of access (e.g., reading data, writing data, appending data, creating data, deleting data or exe- 

is cuting an application) to the requester. 

[0025] The application may be one of a several applications stored in the memory. The processor may be further 
configured to receive a request from a requester to access one of the plurality of applications; after receipt of the 
request, detemiine whether said one of the plurality of applications complies with a predetermined set of rules; and 
based on the detemiinatton, setectivety grant access to the requester to said one of the plurality of applications. The 

20 predetermined rules provide a guide for detennining whether said one of the plurality of applications accesses a pre- 
determined region of the memory. The processor may be further configured to authenticate an identity of the requester 
and grant access to said one of the plurality of applications based on the identity. 

[0026] The processor may be also configured to interact with the terminal via the communicator to authenticate an 
identity; detemiine if the identity has been authenticated; and based on the detenmlnation, selectively allow communi- 

25 cation between the terminal and the integrated circuit card. 

[0027] The communicator and the temiinai may communicate via communication channels. The processor may also 
be configured to assign one of the communication channels to the identity when the processor allows the communication 
between the terminal and the integrated circuit card. The processor may aiso be configured to assign a session l<ey 
to the assigned, communication channel and use the session key when the processor and the temriinal communicate 

30 via the assigned communication channel. 

[0028] The terminal may have a card reader, and the communicator may Include a contact for communicating with 
the card reader. The tenminal may have a wireless communication device, and the communbtor may include a wireless 
transceiver for communicating with the wireless communication devbe. The terminal may have a wireless communi- 
cation device, and the communicator may include a wireless transmitter for communicating with the wireless commu- 

35 nicatlon device. 

[0029] In general, in another aspect, the invention features a method for use with an Integrated circuit card and a 
terminal. The method includes storing an interpreter and at least one applteation having a high level programming 
language fonnat in a memory of the integrated circuit card. A processor of the integrated circuit card uses the interpreter 
to interpret the at least one application for execution, and the processor uses a communicator of the card when com- 
^0 munbating between the processor and the temninat. 

[0030] In general. In another aspect, the invention features a smart card. The smart card includes a memory that 
stores a Java interpreter and a processor that is configured to use the interpreter to interpret a Java application for 
execution. 

[0031] In general, in another aspect, the Invention features a microcontroller that has a semiconductor substrate and 
<5 a memory located in the substrate. A programming language interpreter is stored in the memory and is configured to 
implement security checks. A central processing unit is located in the substrate and is coupled to the memory. 
[0032] implementations of the invention may include one or more of the following. The Interpreter may be a Java 
byte code interpreter. The security checks may include establishing firewalls and may include enforcing a sandbox 
security model. 

50 [0033] In general, in another aspect, the invention features a smart card that has a programming language interpreter 
stored in a memory of the card. The interpreter is configured to implement security check. A central processing unit of 
the card is coupled to the memory. 

[0034] In general, in another aspect, the Invention features an integrated circuit card that is used with a tenninai. 
The card includes a communicator and a memory that stores an interpreter and first instructions of a first application. 
55 The first instructions have been converted from second instructions of a second application. The integrated circuit card 
includes a processor that is coupled to the memory and Is configured to use the interpreter to execute the first instruc- 
tions and to communicate with the temiinai via the communicator. 

[0035] Implementations of the invention may include one or more of the following. The first and/or second applications 
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may have class file format(s). The first and/or second applfcations may include byte codes, such as Java byte codes. 
The first instructions may be generalized or renumbered versions of the second instructions. The second instructions 
may include constant references, and the first instructions may include constants that replace the constant references 
of the second instructions. The second instructions may include references, and the references may shift location 
during the conversion of the second instructions to the first instructions. The first instructions may be relinlced to the 
references after the shifting. The first instructions may include byte codes for a first type of virtual machine, and the 
second instructions may include byte codes for a second type of virtual machine. The first type is different from the 
second type. 

[0036] In general, in another aspect, the invention features a method for use with an integrated circuit card. The 
method includes converting second instructions of a second application to first instructions of a first application; storing 
the first instructions in a memory of the integrated circuit card; and using an interpreter of the integrated circuit card to 
execute the first instructions. 

[0037] In general, in another aspect, the invention features an Integrated circuitfor use with a temninal. The Integrated 
circuit card has a communicator that is configured to communicate with the temiinal and a memory that stores a first 
application that has been processed from a second application having a string of characters. The string of characters 
are represented in the first application by an identifier. The integrated circuit card includes a processor that is coupled 
to the memory. The processor is configured to use the interpreter to interpret the first application for execution and to 
use the communicator to communicate with the terminal. 

[0038] In general, in another aspect, the invention features a method for use with an integrated circuit card and a 
tenninal. The method includes processing a second application to create a first application. The second application 
has a string of characters. The string of characters is represented by an identifier in the second application. An Inter* 
preter and the first application are stored in a memory of the integrated circuit card. A processor uses an interpreter 
to interpret the first application for execution. 

[0039] In general, in another aspect, the invention features a microcontroller that includes a memory which stores 
an application and an interpreter. The application has a class file fonmat. A processor of the microcontroller Is coupled 
to the memory and is configured to use the interpreter to interpret the application for execution, 
[0040] In implementations of the invention, the microcontroller may also include a communicator that is configured 
to communicate with a terminal. 

[0041] In general, in another aspect, the invention features a method for use with an integrated circuit card. The 
method includes storing a first application in a memory of the integrated circuit card, storing a second application in 
the memory of the Integrated circuit card, and creating a firewall that isolates the first and second applications so that 
the second application cannot access either the first application or data associated with the first application. 
[0042] In general, in another aspect, the invention features an integrated circuit card for use with a terminal. The 
integrated circuit card Includes a communicator that is configured to communicate with the temiinal, a memory and a 
processor. The memory stores applications, and each application has a high level programming language fonmat. The 
memory also stores an Interpreter. The processor is coupled to the memory and Is configured to: a.) use the interpreter 
to interpret the applications for execution, b.) use the interpreter to create a firewall to isolate the applications from 
each other, and c.) use the communicator to communicate with the terminal. 

[0043] Other advantages and features will become apparent from the following description and from the claims. 
Brief Description of the Drawing 

[0044] Fig. 1 is a block diagram of an Integrated card system. 

[0045] Fig. 2 is a flow diagram illustrating the preparation of Java applications to be downloaded to an Integrated 
circuit card. 

[0046] Fig. 3 is a block diagram of the files used and generated by the card class file converter. 

[0047] Fig. 4 is a block diagram illustrating the transfomnation of application class file(s) into a card class file. 

[0048] Fig. 5 is a flow diagram illustrating the working of the class file converter 

[0049] Fig. 6 is a flow diagram illustrating the modification of the byte codes. 

[0050] Fig. 7 is a block diagram Illustrating the transfomnation of specific byte codes into general byte codes. 
[0051 ] Fig. 8 is a block diagram illustrating the replacement of constant references with constants. 
[0052] Fig. 9 is a block diagram illustrating the replacement of references with their updated values. 
[0053] Fig. 10 is a block diagram illustrating renumbering of original byte codes. 

[0054] Fig. 1 1 is a block diagram illustrating translation of original byte codes for a different virtual machine architec* 
ture. 

[0055] Fig 12 is a block diagram illustrating loading applications into an integrated circuit card. 
[0056] Fig. 13 is a block diagram illustrating executing applications in an integrated circuit card. 
[0057] Fig. 14 is a schematic diagram Illustrating memory organization for ROM, RAM and EEPROM. 
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[0058] Fig. 15 Is a flow diagram illustrating the overall architecture of the Card Java virtual machine. 

[0059] Fig. 16 Is a flow diagram illustrating method execution in the Card Java virtual machine with the security 

checks. 

[0060] Fig. 1 7 is a fiow diagram iliustrating byte code execution in the Card Java virtual machine. 

[0061] Fig. 1 8 is a flow diagram illustrating method execution in the Card Java virtual machine without the security 

checks. 

[0062] Fig. 1 9 is a block diagram illustrating the association between card applications and identities. 

[0063] Fig. 20 is a block diagram illustrating the access rights of a specific running application. 

[0064] Fig. 21 is a perspective view of a microcontroller on a smart card. 

[0065] Fig. 22 is a perspective view of a microcontroller on a telephone. 

[0066] Fig. 23 Is a perspective view of a microcontroller on a key ring. 

[0067] Fig. 24 is a perspective view of a microcontroller on a ring. 

[0068] Fig. 25 is a perspective view of a microcontroller on a circuit card of an automobile. 



Detailed Description of the Preferred Embodiments 



[0069] Referring to Fig. 1 , an integrated circuit card 10 (e.g., a smart card) is constructed to provide a high level, 
Java-based, multiple application programming and execution environment. The integrated circuit card 10 has a com- 
municator 12a that is configured to communicate with a tenminal communicator 1 2b of a terminal 14. In some embod- 
iments, the integrated circuit card 10 is a smart card with an 8 bit microcontroller, 512 bytes of RAM, 4K bytes of 
EEPROM, and 20K of ROM; the temninal communicator 12b is a conventional contact smart card reader; and the 
temninal 14 is a conventional personal computer ainning the Windows NT operating system supporting the personal 
computer smart card (PC/SC) standard and providing Java development support. 

[0070] In some embodiments, the microcontroller, memory and communicator are embedded in a plastic card that 
has substantially the same dimensions as a typical credit card. In other embodiments, the microcontroller, memory 
and communicator are mounted within bases other than a plastte card, such as jewelry (e.g., watches, rings or brace- 
lets), automotive equipment, telecommunication equipment (e.g., subscriber identity module (SIM) cards), security 
devices (e.g., cryptographic modules) and appliances. 

[0071] The temninal 14 prepares and downloads Java applications to the integrated circuit card 1 0 using the tenminal 
communicator 12b. The terminal communicator 12b is a communications device capable of establishing a communi- 
cations channel between the integrated circuit card 10 and the terminal 14. Some communication options include 
contact card readers, wireless communteations via radio frequency or infrared techniques, serial communication pro- 
tocols, packet communication protocols, ISO 7816 communication protocol, to name a few. 
[0072] The temiinal 14 can also interact with applications running in the Integrated circuit card 10. In some cases, 
different temiinals may be used for these purposes. For example, one kind of tenminal may be used to prepare appli- 
cations, different terminals could be used to download the applicacions, and yet other temiinals could be used to run 
the various applications. Temninals can be automated teller machines (ATMs), point-of-sale temiinals, door security 
systems, toll payment systems, access control systenfis, or any other system that communicates with an integrated 
circuit card or mk^rocontroller 

[0073] The integrated circuit card 1 0 contains a card Java virtual machine (Card JVM) 1 6, which is used to interpret 

applications which are contained on the card 10. 

[0074] Referring to Fig. 2, the Java application 20 includes three Java source code files A.java 20a, B.Java 20b, and 
C.java 20c. These source code files are prepared and compiled in a Java application development environment 22. 
When the Java application 20 is compiled by the development environment 22, application class files 24 are produced, 
with these class files A.class 24a, B.class 24b, and C.class 24c con^esponding to their respective class Java source 
code 20a. 20b, and 20c. The application class files 24 follow the standard class file fomnat as documented in chapter 
4 of the Java virtual machine specification by Tim Lindholm and Frank Yellin, The Java Virtual Machine Specification," 
Addison-Wesley, 1 996. These application class files 24 are fed into the card class file converter 26, whfeh consolidates 
and compresses the files, producing a single card class file 27. The card class file 27 is loaded to the integrated circuit 
card 10 using a conventional card loader 28. 

[0075] Referring to Fig. 3, the card class file converter 26 Is a class file postprocessor that processes a set of class 
files 24 that are encoded in the standard Java class file format, optionally using a string to ID input map file 30 to 
produce a Java card class file 27 in a card dass file fonmat. One such card class file fomnat is described in Appendix 
A. In addition, in some embodiments, the card class file converter 26 produces a string to ID output map file 32 that is 
used as input for a subsequent execution of the card class file converter 

[0076] In some embodiments, in order for the string to ID mapping to be consistent with a previously generated card 
class file (in the case where multiple class files reference the same strings), the card class file converter 26 can accept 
previously defined string to ID mappings from a string to ID input map file 30. In the absence of such a file, the IDs are 
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generated by the card class file converter 26. Appendix B describes one possible way of implementing and producing 
the string to ID input map file 30 and string to ID output map file 32 and illustrates this mapping via an example. 
[0077] Referring to Fig. 4, a typical application class file 24a includes class file infomnation 41 ; a class constant pool 
42; class, fields created, interfaces referenced, and method Information 43; and various attribute Information 44, as 

5 detailed in aforementioned Java Virtual Machine Specification. Note that much of the attribute infomnation 44 is not 
needed for this embodiment and is eliminated 45 by the card class file converter 26. Eliminated attributes include 
SourceFile, ConstantValue. Exceptions, LineNumberTable, LocalVariableTable, and any optional vendor attributes. 
The typical card class file 27 as described in Appendix A is derived from the application class files 24 In the following 
manner. The card class file Infonmation 46 Is derived from the aggregate class file information 41 of all application class 

10 flies 24a. 24b, and 24c. The card class file constant pool 47 Is derived from the aggregate class constant pool 42 of 
all application class files 24a, 24b, and 24c. The card class, fields created, Interfaces referenced, and method Infor- 
mation 48 is derived from the aggregate class, fields created, interfaces referenced, and method infomnation 43 of all 
application class files 24a, 24b. and 24c. The card attribute infomnation 49 in this embodiment is derived from only the 
code attribute of the aggregate attribute information 44 of all application class files 24a, 24b, and 24c. 

15 [0078] To avoid dynamic linking in the card, all the Information that is distributed across several Java class files 24a, 
24b, and 24c that fonn the application 24, are coalesced into one card class file 27 by the process shown in the flowchart 
in Fig. 5. The first class file to be processed is selected 51a. The constant pool 42 is compacted 51b in the following 
manner. All objects, classes, fields, methods referenced in a Java class file 24a are identified by using strings in the 
constant pool 42 of the class file 24a. The card class file converter 26 compacts the constant pool 42 found In the Java 

20 class file 24a into an optimized version. This compaction Is achieved by mapping all the strings found in the class file 
constant pool 42 Into integers (the size of which Is microcontroller architecture dependent). These Integers are also 
refen-ed to as IDs. Each ID uniquely identifies a particular object, class, field or method in the application 20. Therefore, 
the card class file converter 26 replaces the strings in the Java class file constant pool 42 with its corresponding unique 
ID. Appendix B shows an example application HelloSmartCard.java, with a table below illustrating the IDs correspond- 

25 ing to the strings found in the constant pool of the class file for this application. The IDs used for this example are 1 6-bit 
unsigned integers. 

[0079] Next, the card class file converter 26 checks for unsupported features 51c In the Code attribute of the input 
Java class file 24a. The Card JVI\^ 16 only supports a subset of the full Java byte codes as described in Appendix C. 
Hence, the card dass file converter 26 checks for unsupported byte codes In the Code attribute of the Java class file 

30 24a. If any unsupported byte codes are found 52, the card class file converter flags an error and stops conversion 53. 
The program code fragment marked "A" in APPENDIX D shows how these spurious byte codes are apprehended. 
Another level of checking can be performed by requiring the standard Java development environment 22 to compile 
the application 20 with a '-g' flag. Based on the aforementioned Java virtual machine specification, this option requires 
the Java compiler to place infonnatlon about the variables used In a Java application 20 In the LocalVariableTable 

35 attribute of the class file 24a. The card class file converter 26 uses this Infonnation to check If the Java class file 24a 
references data types not supported by the Java card. 

[0080] Next, the card class file converter 26 discards all the unnecessary parts 51c of the Java class file 24a not 
required for Interpretation. A Java class file 24a stores Infomnation pertaining to the byte codes in the class file in the 
Attributes section 44 of the Java class file. Attributes that are not required for interpretation by the card JVM 16, such 
<o as SourceFile, ConstantValue, Exceptions, LineNumberTable, and LocalVariableTable may be safely discarded 45. 
The only attribute that Is retained is the Code attribute. The Code attribute contains the byte codes that correspond to 
the methods in the Java class file 24a. 

[0081] Modifying the byte codes 54 involves examining the Code attribute information 44 for each method in the 
class file, and modifying the operands of byte codes that refer to entries in the Java class file constant pool 42 to reflect 
45 the entries in the card class file constant pool 47. In some embodiments, the byte codes are also modified, as described 

below. 

[0082] Modifying the byte codes 54 involves five passes (with two optional passes) as described by the flowchart in 
Fig. 6. The original byte codes 60 are found in the Code attribute 44 of the Java class file 24a being processed. The 
first pass 61 records all the jumps and their destinations in the original byte codes. During later byte code translation. 

50 some single byte code may be translated to dual ortriple bytes. Fig. 7 illustrates an example wherein byte code ILOAD_0 
is replaced with two bytes, byte code ILOAD and argument 0. When this Is done, the code size changes, requiring 
adjustment of any jump destinations which are affected. Therefore, before these transformations are made, the original 
byte codes 60 are analyzed for any jump byte codes and a note made of their position and current destination. The 
program code fragment marked "B" in Appendix D shows how these jumps are recorded. 

55 [0083] Once the jumps are recorded, if the optional byte code translation is not being performed 62, the card class 
file converter 26 may proceed to the third pass 64. 

[0084] Otherwise, the card class file converter converts specific byte codes into generic byte codes. Typically, the 
translated byte codes are not Interpreted in the Card JVM 16 but are supported by converting the byte codes into 
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equivatent byte codes that can be interpreted by the Card JVM 16 (see Rg. 7). The byte codes 70 may be replaced 

with another semantically equivalent but different byte codes 72. This generally entails the translation of short single 
specific byte codes such as ILOAD_0 Into their more general versions. For example, ILOAD_0 may be replaced by 
byte code (LOAD with an argument 0. This translation is done to reduce the number of byte codes translated by the 

5 Card JVM 1 6, consequently reducing the complexity and code space requirements for the Card JVM 1 6. The program 
code fragment marked "C" in Appendix D shows how these translations are made. Note that such translations increase 
the size of the resulting byte code and force the re-computation of any jumps which are affected. 
[0085] In the third pass 64, the card class file converter rebuilds constant references via elimination of the strings 
used to denote these constants. Fig. 8 shows an example wherein the byte code LDC 80 referring to constant "18" 

^0 found via an index in the Java class file 24a constant pool 42 may be translated Into BIPUSH byte code 82. In this 
pass the card class file converter 26 modifies the operands to all the byte codes that refer to entries in the Java class 
file constant pool 42 to reflect their new location in the card class file constant pool 47. Fig. 9 shows an example wherein 
the argument to a byte code, INVOKESTATIC 90, refers to an entry in the Java class file constant pool 42 that is 
modified to reflect the new location of that entry in the card class file constant pool 47. The modified operand 94 shows 

IS this transfonnation. The program code fragment marked "D" in Appendix D shows how these modifications are made. 
[0086] Once the constant references are relinked, if the optional byte code modifbation is not being perfomned, the 
card class file converter may proceed to the fifth and final pass 67. 

[0087] Otherwise, the card class file converter modifies the original byte codes into a different set of byte codes 
supported by the particular Card JVM 1 6 being used. One potential modification renumbers the original byte codes 60 

20 Into Card JVM 1 6 byte codes (see Fig. 1 0). This renumbering causes the byte codes 1 00 in the original byte codes 60 
to be modified into a renumbered byte codes 102. Byte code ILOAD recognized by value 21 may be renumbered to 
be recognized by value 50. This modification may be done for optimizing the type tests (also known In prior art as Pass 
3 checks) In the Card JVM 16. The program code fragment marked "E" In Appendix D shows an implementation of 
this embodiment. This modification may be done in order to reduce the program space required by the Card JVM 16 

25 to interpret the byte code. Essentially this modification regroups the byte codes into Card JVM 1 6 byte codes so that 
byte codes with similar operands, results are grouped together, and there are no gaps between Card JVM 16 byte 
codes. This allows the Card JVM 1 6 to efficiently check Card JVM 1 6 byte codes and validate types as it executes. 
[0088] In some embodiments, the card class file converter modifies the original byte codes 60 into a different set of 
byte codes designed for a different virtual machine architecture, as shown in Fig. 11 . The Java byte code ILOAD 112 

30 intended for use on a word stack 1 1 4 may be replaced by Card JVM 1 6 byte code ILOAD_B 11 6 to be used on a byte 
stack 118. An element in a word stack 114 requires allocating 4 bytes of stack space, whereas an element In the byte 
stack 118 requires only one byte of stack space. Although this option may provide an increase in execution speed, it 
risks losing the security features available in the original byte codes. 

[0089] Since the previous steps 63, 64 or 66 may have changed the size of the byte codes 60 the card class file 

35 converter 26 has to relink 67 any jumps whfch have been effected. Since the jumps were recorded in the first step 61 
of the card class file converter 26, this adjustment is carried out by fixing the jump destinations to their appropriate 
values. The program code fragment marked "P in Appendix D shows how these jumps are fixed. 
[0090] The card class file converter now has modified byte codes 68 that is equivalent to the original byte codes 60 
ready for loading. The translation from the Java class file 24a to the card class file 27 Is now complete. 

40 [0091 ] Referring back to Fig. 5, if more class files 24 remain to be processed 55 the previous steps 51 a, 51 b, 51 c, 
52 and 54 are repeated for each remaining class file. The card class file converter 26 gathers 56 the maps and modified 
byte codes for the classes 24 that have been processed, places them as an aggregate and generates 67 a card class 
file 27. If required, the card class file converter 26 generates a string to ID output map file 32, that contains a list of all 
the new IDs allocated for the strings encountered In the constant pool 42 of the Java class files 24 during the translation. 

45 [0092] Refenring to Fig. 12, the card loader 28 within the temriinal 14 sends a card class file to the loading and 
execution control 120 within the integrated circuit card 10 using standard ISO 7816 commands. The loading and ex- 
ecution control 120 with a card operating system 122, which provides the necessary system resources, including sup- 
port for a card file system 124, which can be used to store several card applications 126. Many conventional card 
loaders are written in low level languages, supported by the card operating system 122. In the preferred embodiment, 

so the bootstrap loader is written In Java, and the Integrated circuit card 10 Includes a Java virtual machine to run this 
application. A Java Implementation of the loading and execution control 120 is illustrated in Appendix E. The loading 
and execution control 120 receives the card class file 26 and produces a Java card application 126x stored In the card 
file system 126 in the EEPROM of the Integrated circuit card 1 0. Multiple Java card applications 126x, 126y, and 126z 
can be stored in a single card in this manner. The loading and execution control 120 supports commands whereby the 

ss terminal 14 can select whtoh Java card application to run immediately, or upon the next card reset. 

[0093] Refenring to Fig. 1 3, upon receiving a reset or an execution command from the loading and execution control 
120, the Card Java Virtual Machine (Card JVM) 16 begins execution at a predetemiined method (for example, main) 
of the selected class in the selected Java Card application 126z. The Card JVM 16 provides the Java card application 
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126z access to the underlying card operating system 122, which provides capabilities such as I/O, EEPROM support, 
file systems, access control, and other system functions using native Java methods as illustrated in Appendix F. 
[0094] The selected Java card application 126z communicates with an appropriate application in the terminal 14 
using the communicator 12a to establish a communication channel to the temnlnal 14. Data from the communicator 

5 12a to the tenninal 14 passes through a communicator driver 1 32 in the temilnal, which is specifically written to handle 
the communications protocol used by the communicator 12a. The data then passes to an integrated circuit card driver 
134, which is specifically written to address the capabilities of the particular integrated circuit card 10 being used, and 
provides high level software services to the temriinal application 136. In the prefeaed embodiment, this driver would 
be appropriate PC/SC Smartcard Service Provider (SSP) software. The data then passes to the temninal application 

io 136, which must handle the capabilities provided by the particular card application 126z being run. In this manner, 
commands and responses pass bacic and forth between the temiinal application 136 and the selected card application 
1262. The terminal application interacts with the user, receiving commands from the user, some of which are passed 
to the selected Java card application 126z, and receiving responses from the Java card application 126z, which are 
processed and passed back to the user 

15 [0095] Referring to Fig. 14, the Card JVI\4 16 is an interpreter that interprets a card application 126x. The memory 
resources in the microcontroller that Impact the Card JVM 1 6 are the Card ROM 140, Card RAM 141 and the Card 
EEPROM 1 42. The Card ROM 1 40 is used to store the Card JVM 1 6 and the card operating system 1 22. Card ROM 
140 may also be used to store fixed card applications 140a and class libraries 140b. Loadable applications 141 a, 141b 
and libraries 141c may also be stored in Card RAM 141 . The Card JVM 16 interprets a card application 141a, 141 b, 

20 or 1 40a. The Card JVM 1 6 uses the Card RAM to store the VM stacl< 1 44a and system state variables 1 44b. The Card 
JVM 16 keeps track of the operations performed via the VM stack 144a. The objects created by the Card JVM 16 are 
either on the RAM heap 144c, in the EEPROM heap 146a, or in the file system 147. 

[0096] All of the heap manipulated by the Card JVM 16 may be stored in the Card RAM 141 as a RAM Heap 144c, 
or it may be distributed across to the Card EEPROM 142 as a EEPROM Heap 146a. Card RAM 141 is also used for 

25 recording the state of the system stack 14B that is used by routines written in the native code of the microcontroller. 
The Card JVM 16 uses the Card EEPROM 142 to store application data either In the EEPROM heap 146a or In the 
file system 1 47. Application data stored in a file may be manipulated via an Interface to the card operating system 1 22. 
This interface Is provided by a class library 140b stored in Card ROM 140, by a loadable class library 141c stored in 
Card EEPROM 142. One such interface is described in Appendix F. Applications and data in the card are isolated by 

30 a firewall mechanism 149. 

[0097] To cope with the limited resources available on microcontrollers, the Card JVM 1 6 implements a strict subset 
of the Java programming language. Consequently, a Java application 20 compiles into a class file that contains a strict 
subset of Java byte codes. This enables application programmers to program in this strict subset of Java and still 
maintain compatibility with existing Java Virtual Machines. The semantics of the Java byte codes Interpreted by the 

35 Card JVM 1 6 are described in the aforementioned Java Virtual Machine Specification. The subset of byte codes inter- 
preted by the Card JVM 1 6 can be found in Appendix C. The card class file converter 26 checks the Java application 
20 to ensure use of only the features available in this subset and converts into a form that is understood and Interpreted 
by the Card JVM 16. 

[0098] In other embodiments, the Card JVM 1 6 is designed to interpret a different set or augmented set of byte codes 
40 116. Although a different byte code set might lead to some performance improvements, departing from a strict Java 
subset may not be desirable from the point of view of security that is present in the original Java byte codes or com- 
patibility with mainstream Java development tools. 

[0099] All Card JVM 16 applications 126 have a defined entry point denoted by a class and a method in the class. 
This entry point is mapped in the string to ID input map 30 and assigned by the card class file converter 26. Classes, 
45 methods and fields within a Java application 20 are assigned IDs by the card class file converter 26. For example, the 
ID corresponding to the main application class may be defined as F001 and the ID corresponding to its main method, 
such as "maln()V" could be defined as F002. 

[0100] The overall execution architecture of the Card JVM is described by the flowchart in Fig. 15. Execution of the 
Card JVM 16 begins at the execution control 120, which chooses a card application 126z to execute. It proceeds by 

50 finding and assigning an entry point 152 (a method) in this card application for the Card JVM 16 to interpret. The Card 
JVM 16 interprets the method 153. If the interpretation proceeds successfully 154, the Card JVM 16 reports success 
1 55 returning control back to the execution control 1 20. if in the course of interpretation 1 53 the Card JVM 1 6 encounters 
an unhandted error or exception (typically a resource limitation or a security violation), the Card JVM 1 6 stops 156 and 
reports the appropriate error to the tenminal 14. 

55 [0101] An essential part of the Card JVM 16 is a subroutine that handles the execution of the byte codes. This 
subroutine Is described by the flowchart in Fig. 16, Given a method 1 60 it executes the byte codes in this method. The 
subroutine starts by preparing for the parameters of this method 1 61 . This involves setting the VM stack 144a pointer, 
VM stack 144a frame limits, and setting the program counter to the first byte code of the method. 
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[01 02] Next, the method flags are checked 1 62. If the method is flagged native, then the method Es actually a call to 
native method code (subroutine written In the microcontroller's native processor code). In this case, the Card JVM 16 
prepares for an efficient call 163 and return to the native code subroutine. The parameters to the native method may 
be passed on the VM stack 144a or via the System stack 148. The appropriate security checks are made and the 
5 native method subroutine is called. On return, the result (if any) of the native method subroutine is placed on the VM 
stack 144a so that it may be accessed by the next byte code to be executed. 

[0103] The dispatch loop 164 of the Card JVM 16 Is then entered. The byte code dispatch loop is responsible for 
preparing, executing, and retiring each byte code. The loop terminates when it finishes interpreting the byte codes In 
the method 160, or when the Card JVM 16 encounters a resource limitation or a security violation. 
10 [0104] If a previous byte code caused a branch to be taken 165 the Card JVM prepares for the branch 1 65a. The 
next byte code is retrieved 165b. In order to keep the cost of processing each byte code down, as many common 
elements such as the byte code arguments, length, type are extracted and stored. 

[0105] To provide the security offered by the security model of the programming language, byte codes in the class 
file must be verified and detemnined confonnant to this model. These checks are typically carried out In prior art by a 

IS program referred to as the byte code verifier, which operates in four passes as described in the Java Virtual Machine 
Specif Nation. To offer the run-time security that is guaranteed by the byte code verifier, the Card JVM 1 6 must perfonm 
the checks that pertain to the Pass 3 and Pass 4 of the verifier. This checking can be bypassed by the Card JVM 16 
if it can be guaranteed (which Is almost Impossible to do) that the byte codes 60 interpreted by the Card JVM 16 are 
secure. At the minimum, code security can be maintained as long as object references cannot be faked and the VM 

20 stack 1 44a and local variable bounds are observed. This requires checking the state of the VM stack 1 44a with respect 
to the byte code being executed. 

[0106] To enforce the security model of the programming language, a 256-byte table is created as shown in Appendix 
G which. This table is indexed by the byte code number. This table contains the type and length information associated 
with the Indexing byte code. It Is encoded with the first 5 bits representing type, and the last 3 bits representing length. 

25 The type and length of the byte code is indexed directly from the table by the byte code number. This type and length 
is then used for checking as shown in Appendix H. In Appendix H, the checking process begins by decoding the length 
and type from the table in Appendix G. The length is used to increment the program counter. The type is used first for 
pre-execution checking, to insure that the data types on the VM stack 144a are correct for the byte code that is about 
to be executed. The 256 bytes of ROM for table storage allows the original Java byte codes to be run In the Card JVM 

30 16 and minimizes the changes required to the Java class file to be loaded in the card. Additional Java byte codes can 
be easily supported since It Is relatively easy to update the appropriate table entries. 

[0107] In other embodiments, as shown in Fig. 10, the Java byte codes in the method are renumbered in such a 
manner that the byte code type and length infomnation stored in the table in Appendix H is implicit in the reordering. 
Consequently, the checks that must be perfonned on the state of the VM stack 1 44a and the byte code being processed 
35 does not have to Involve a table look up. The checks can be pertomied by set of simple comparisons as shown in 
Appendix I. This embodiment is preferable when ROM space is at a premium, since it eliminates a 256-byte table. 
However adding new byte codes to the set of supported byte codes has to be carefully thought out since the new byte 
codes have to fit in the impltoit numbering scheme of the supported byte codes. 

[0108] In another embodiment, the Card JVM 1 6 chooses not to perf omn any security checks in favor of Card JVM 
40 16 execution speed. This is illustrated in the flowchart in Fig. 18. The flow chart in Fig. 18 is the same as that of Fig. 
16 with the security checks removed. This option is not desirable from the point of view of security, unless it can be 
guaranteed that the byte codes are secure. 

[01 09] The Card JVM 1 6 may enforce other security checks as well. If the byte code may reference a local variable, 
the Card JVM 16 checks if this reference is valid, throwing an error If it Is not. If the reference is valid, the Card JVM 
^5 16 stores the type of the local variable for future checking. The VM stack 144a pointer is checked to see if it is still in 
a valid range. If not an exception is thrown. The byte code number is checked. If it is not supported, an exception is 
thrown. 

[0110] Finally, the byte code itself Is dispatched 165d. The byte codes translated by the Card JVM 16 are listed in 
Appendix C. The semantics of the byte codes are described in the aforementioned Java Virtual Machine Specification 

50 with regard to the state of the VM stack 144a before and after the dispatch of the byte code. Note also that some byte 
codes (the byte codes, INVOKESTATIC, INVOKESPECIAL, INVOKENON VIRTUAL and INVOKEVIRTUAL) may cause 
reentiy into the Card JVM 16, requiring processing to begin at the entry of the subroutine 161. Fig. 17 shows the 
flowchart of the byte code execution routine. The routine Is given a byte code 1 71 to execute. The Card JVM 1 6 executes 
172 the instructions required for the byte code. If in the course of executing the Card JVM 16 encounters a resource 

S5 limitation 173, it returns an error 156. This error is returned to the terminal 16 by the Card JVM 16. if the byte code 
executes successfully, it returns a success 175. 

[01 1 1 ] After execution, the type of the result is used to set the VM stack 1 44a state correctly 1 65e, properly flagging 
the data types on the VM stack 144a. The byte code information gathered previously 165b from the byte code Info 
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table is used to set the state of the VM stack 144a in accordance with the byte code that just executed. 
[01 12J In other embodiments, setting the output state of the VM stack 144a with respect to the byte code executed 
is simplified if the byte code is renumbered. This is shown in Appendix I which is hereby incoiporated by reference. 
[01131 In yet another embodiment, the Card JVM 16 may bypass setting the output state of the VM stack 144a in 
5 favor of Card JVM 1 6 execution speed. This option is not desirable from the point of view of security, unless it can be 
guaranteed that the byte codes are secure. 

[0114] After the byte code has been executed, the byte code is retired 165f. This involves popping arguments off 
the VM stack 144a. Once byte code processing is completed, the loop 164 is repeated for the next byte code for the 
method. 

io [01 1 51 Once the dispatch loop 1 64 temninates. the VM stack 1 44a is emptied 1 66. This prevents any object references 
filtering down to other Card JVM 16 invocations and breaking the Card JVM's 16 security. Temrtination 167 of the byte 
code dispatch loop 164 indicates that the Card JVM 16 has completed executing the requested method. 
[0116] To isolate data and applications in the integrated circuit card 10 from each other, the integrated circuit card 
1 0 relies on the firewall mechanism 1 49 provided by the Card JVM 1 6, Because the Card JVM implements the standard 

15 pass 3 and pass 4 verifier checks, it detects any attempt by an application to reference the data or code space used 
by another application, and flag a security en^or 156. For example, conventional low level applications can cast non- 
reference data types into references, thereby enabling access to unauthorized memory space, and violating security. 
With this invention, such an attempt by a card application 1262 to use a non-reference data type as a reference will 
trigger a security violation 156. In conventional Java, this protected application environment is referred to as the sand- 

20 box application-interpretation environment. 

[01 1 7] However, these firewall facilities do not woric independently. In fact, the facilities are overlapping and mutually 
reinforcing with conventional access control lists and encryption mechanisms shown In the following table: 
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[01 1 8] Taken together, these facilities Isolate both data and applications on the integrated circuit card 1 0 and ensure 
that each card application 126 can access only the authorized resources of the integrated circuit card 10. 
[0119] Referring to Fig. 19, card applications 126x, 126y, 126z can be endowed with specific privileges when the 
card applications 126 execute. These privileges detennine, for example, which data files the card applications 126 can 
^ access and what operations the card applications 126 can perform on the file system 147. The privileges granted to 
the card applications 126 are nonnally set at the time that a particular card application 126z is started by the user, 
typically from the tennlnat 14. 

[0120] The integrated circuit card 10 uses ciyptographlc identification verification methods to associate an identity 
1 90 (e.g., identities 1 90a, 1 90b and 1 90c) and hence, a set of privileges to the execution of the card application 126. 
25 The association of the specific identity 1 90c to the card application 1 26z is made when the card application 1 26z begins 
execution, thus creating a specific running application 200, as shown in Fig. 20. The Identity 190 is a unique legible 
text string reliably associated with an identity token. The identity token (e.g., a personal identifk:ation number (PIN) or 
a RSA private key) is an encryption key. 

[0121] Referring to Fig. 20, in order to run a specific card application 126z, the identity 190c of the card application 
30 I26z must be authenticated. The identity 190c is authenticated by demonstrating knowledge of the identity token as- 
sociated with the identity 190c. Therefore, in order to run the card application 126z, an agent (e.g., a card holder or 
another application wishing to run the application) must show that it possesses or knows the application's identity- 
defining encryption key. 

[0122] One way to demonstrate possession of an encryption key is simply to expose the key itself. PIN verification 
35 Is an example of this fomri of authentication. Another way to demonstrate the possession of an encryption key without 
actually exposing the key itself is to show the ability to encrypt or decrypt plain text with the key 
[0123] Thus, a specific running application 200 on the integrated circuit card 10 Includes a card application 126z 
plus an authenticated identity 190c. No card application 126 can be run without both of these elements being in place. 
The card application 126z defines data processing operations to be perfomied, and the authenticated Identity 190c 
40 determines on what computational objects those operations may be performed. For example, a specific application 
126z can only access identity C's files 202 in the file system 147 associated with the specific identity 190c, and the 
specific card application 126z cannot access other files 204 that are associated with identities other than the specific 
identity 190c. 

[01 24] The integrated circuit card 1 0 may take additional steps to ensure application and data isolation. The integrated 
45 circuit card 1 0 furnishes three software features sets: authenticated-ldentity access control lists; a Java-based virtual 
machine; and one-time session encryption keys to protect data files, application execution, and communication chan- 
nels, respectively. Collectively, for one embodiment, these features sets provide the appibation data firewalls 149 for 
one embodiment. The following discusses each software feature set and then shows how the three sets work together 
to Insure application and data isolation on the integrated circuit card 10. 
50 [01 25] An access control list (ACL) is associated with every computational object (e.g., a data file or a communication 
channel) on the integrated circuit card 1 0 that Is be protected, i.e., to which access is to be controlled. An entry on an 
ACL (for a particular computational object) is in a data format referred to as an e-tuple: 

type:identity:permissions 

55 

The type field indicates the type of the following identity (in the Identity field), e.g., a user (e.g., "John Smith"), or a 
group. The penmissions field indicates a list of operations (e.g., read, append and update) that can be performed by 
the Identity on the computational object. 
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[0126] As an example, for a data file that has the ACL entry: 
USER:AcmeAirnnes:RAU, 

5 any application whose identity is "AcmeAirlines" can read fR"), append ("A") and update fU") the data file. In addition, 
the ACL may be used selectively to pennit the creation and deletion of data files. Furthemriore, the ACL may be used 

selectively to pennit execution of an application. 

[0127] Whenever a computational object is accessed by a running application 200, the access is intercepted by the 
Card JVM 16 and passed to the card operating system 122, which detemnines if there is an ACL associated with the 
10 object. If there is an associated ACL, then the identity 1 90c associated with the running application 200 is matched on 
the ACL. If the identity is not found or if the identity is not pemnitted for the type of access that is being requested, then 

the access is denied. Othenwise, the access is allowed to proceed. 

[0128] Referring to Fig. 13, to prevent the potential problems due to the single data path between the integrated 
circuit card 10 and the terminal 14, communication channel isolation is accomplished by including in the identity au- 

15 thentication process the exchange of a one-time session key 209 between the a card application 1 26z and the temnlnat 
application 1 36. The key 209 Is then used to encrypt subsequent traffic between the authenticating temiinal application 
136 and the authenticated card application 126z. Given the one-time session key 209, a rogue terminal application 
can neither "listen in" on an authenticated communication between the tennlnal 14 and the integrated circuit card 10, 
nor can the rogue temninal application "spoof the card application into performing unauthorized operations on its behalf. 

20 [0129] Encryption and decryption of card/tenninal traffic can be handled either by the card operating system 122 or 
by the card applrcation Itself 126z. In the fomner case, the communication with the temninal 14 is being encrypted 
transparently to the application, and message traffic an^ives decrypted in the data space of the application. In the latter 
case, the card application 126z elects to perform encryption and decryption to provide an extra layer of security since 
the application could encrypt data as soon as it was created and would decrypt data only when it was about to be used. 

25 otherwise, the data would remain encrypted with the session key 209. 

[0130] Thus, the application firewall includes three mutually reinforcing software sets. Data files are protected by 
authentk:ated-identity access control lists. Application execution spaces are protected by the Card JVM 16. Commu- 
nication channels are protected with one-time session encryption keys 209. 

[0131] In other embodiments, the above-described techniques are used with a microcontroller (such as the processor 

30 12) may control devices (e.g., part of an automobile engine) other than an integrated circuit card. In these applications, 
the microcontroller provides a small piatfomn (i.e., a central processing unit, and a memory, both of which are located 
on a semiconductor substrate) for storing and executing high level programming languages. Most existing devices and 
new designs that utilize a microcontroller could use this invention to provide the ability to program the microcontroller 
using a high level language, and application of this invention to such devices is specifically included. 

35 [01 32] The term application includes any program, such as Java applications, Java applets, Java aglets, Java serv- 
lets, Java commlets, Java components, and other non-Java programs that can result in class files as described below. 
[0133] Class files may have a source other than Java program files. Several programming languages other than 
Java also have compilers or assemblers for generating class files from their respective source files. For example, the 
programming language Eiffel can be used to generate class files using Pimiin Kalberer's "J- Eiffel", an Eiffel compiler 

40 with JVM byte code generation (web site: http://www.spin.ch/-kalberer/jive/index.htm). An Ada 95 to Java byte code 
translator is described in the following reference : Taft, S. Tucker, "Programming the Internet in Ada 95", proceedings 
of Ada Europe '96, 1996. Jasmin is a Java byte code assembler that can be used to generate class files, as described 
in the following reference : Meyer, Jon and Troy Downing, "Java Virtual Machine", O'Reilly, 1997. Regardless of the 
source of the class flies, the above description applies to languages other than Java to generate codes to be interpreted. 

45 [0134] Fig. 21 shows an integrated circuit card, or smart card, which includes a microcontroller 21 0 that is mounted 
to a plastic card 212. The plastic card 212 has approximately the same fonn factor as a typical credit card. The com- 
municator 12a can use a contact pad 214 to establish a communication channel, or the communicator 12a can use a 
wireless communication system. 

[0135] In other embodiments, a microcontroller 210 Is mounted into a mobile or fixed telephone 220, effectively 
50 adding smart card capabilities to the telephone, as shown in Fig. 22. In these embodiments, the microcontroller 210 
Is mounted on a module (such as a Subscriber Identity Module (SIM)), for insertion and removal from the telephone 220. 
[0136] In other embodiments, a microcontroller 21 0 is added to a key ring 230 as shown in Fig. 23. This can be used 
to secure access to an automobile that is equipped to recognize the identity associated with the microcontroller 210 
on the key ring 230. 

55 [0137] Jewelry such as a watch or ring 240 can also house a microcontroller 210 in an ergonomic manner, as shown 
in Fig, 24. Such embodiments typically use a wireless communication system for establishing a communteation channel, 
and are a convenient way to implement access control with a minimum of hassle to the user. 
[0138] Fig. 25 Illustrates a mrcrocontroller 21 0 mounted in an electrical subsystem 252 of an automobile 254. In this 
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embodtment, the mterocontroller is used for a variety of purposes, such as to controlling access to the automobile, (e. 
g. checking identity or sobriety before enabling the Ignition system of the automobile), paying tolls via wireless com- 
munication, or Interfacing with a global positioning system (GPS) to track the location of the automobile, to name a few. 
[01 39) While specific embodiments of the present Invention have been described, various modifications and substi- 
5 tutlons will become apparent to one skilled in the art by this disclosure. Such modifications and substitutions are within 
the scope of the present invention, and are intended to be covered by the appended claims. 

APPENDIX A 

10 Card Class File Format For Preferred Embodiment 
Introduction 

[0140] The card class file is a compressed fonn of the original class file(s). The card class file contains only the 
15 semantk: infomiatlon required to Interpret Java programs from the original class files. The indirect references In the 
original class file are replaced with direct references resulting in a compact representation. 
[0141] The card class file fonnat is based on the following principles: 

Stay dose to the standard class file formatJhe card class file format should remain as close to the standard 
20 class file fonnat as possible. The Java byte codes in the class file remain unaltered. Not altering the byte codes 

ensures that the structural and static constraints on them remain verifiably intact. 

Ease of implementation: The card class file fomiat should be simple enough to appeal to Java Virtual Machine 
implementers. It must allow for different yet behaviorally equivalent implementations. 

25 

Feasibility: The card class file fomiat must be compact in order to accommodate smart card technology. It must 
meet the constraints of today's technology while not losing sight of tomorrow's innovations. 

[0142] This document is based on Chapter 4. The class file fonriat", In the book titled "The Java^" Virtual Machine 
30 Specif ication"[1 ], henceforth referred to as the Red book. Since the document is based on the standard class file fomriat 
described In the Red book, we only present information that is different. The Red book serves as the final authority for 
any clarification. 

[01 43] The primary changes from the standard class file format are: 

35 The constant pool is optimized to contain only 16-bit identifiers and, where possible, indirection is replaced by a 

direct reference. 

Attributes in the original class file are eliminated or regrouped. 
The Java Card class File Fonnat 

40 

[01 44] This section describes the Java Card class file format. Each card class file contains one or many Java types, 
where a type may be a class or an interface. 

[0145] A card class file consists of a stream of 8-bit bytes. Alt 1 6-bit,. 32-bit, and 64-bit quantities are constructed by 
reading In two. four, and eight consecutive 8-btt bytes, respectively. Multi-byte data items are always stored in big- 
endian order, where the high bytes come first. In Java, this fomiat Is supported by interfaces javaJo.Datalnput and 
java.io.DataOutput and classes such as java.io.DatalnputStream and java.io.DataOutputStream. 
[0146] We define and use the same set of data types representing Java class file data: The types u1, u2, and u4 
represent an unsigned one-, two-, or four-byte quantity, respectively. In Java, these types may be read by methods 
such as readUnsignedByte, readUnsignedShort, and readint of the interface java.io.Datalnput. 
50 [01 47] The card class file f onmat is presented using pseudo-structures written in a C-like structure notation. To avoid 
confusion with the fields of Java Card Virtual Machine classes and class instances, the contents of the structures 
describing the card class file fomnat are referred to as items. Unlike the fields of a C structure, successive items are 
stored in the card class file sequentially, without padding or alignment. 

[0148] Variable-sized tables, consisting of variable-sized items, are used in several class file structures. Although 
ss we will use C-like array syntax to refer to table items, the fact that tables are streams of varying-sized structures means 
that it Is not possible to directly translate a table index Into a byte offset Into the table. 
[0149] Where we refer to a data structure as an array, it is literally an array. 

[0150] In order to distinguish between the card class file structure and the standard class file structure, we add 
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capitalization; for example, we rename field.info in the original class file to Reldlnfo in the card class file. 
Card Class File 

5 [01 51 ] A card class file contains a single CardClassFile structure: 

CardClassFile{ 
u1 major version; 
u1 mlnor^verslon; 
u2 namejndex; 
u2 const_slze; 
u2 max_class; 

Cplnfo constant j)ool[consLsize]; 
Classinfo class[max.class]; 

20 } 

[01 52] The items in the CardClassFile structure are as follows: 
minor_versIon, maJor.versKon 

25 

[0153] The values of the minor^version and major^verslon items are the minor and major version numbers of the 
off-card Java Card Virtual Machine that produced this card class file. An implementation of the Java Card Virtual Ma- 
chine normally supports card class files having a given major version number and minor version numbers 0 through 
some particular minor version. 
30 [01 54] Only the Java Card Forum may define the meaning of card class file version numbers. 

namejndex 

[0155] The value of the namejndex Item must represent a valid Java class name. The Java class name represented 
35 by name_index must be exactly the same Java class name that corresponds to the main application that is to run in 
the card. A card class file contains several classes or interfaces that constitute the application that runs In the card. 
Since Java allows each class to contain a main method there must be a way to distinguish the class file containing the 
main method which corresponds to the card application. 

40 const_size 

[01 56] The value of const.size gives the number of entries in the card class file constant pool. A constant_pool index 
is considered valid if it is greater than or equal to zero and less than const_size. 

45 max.class 

[0157] This value refers to the number of classes present in the card class file. Since the name resolution and linking 
in the Java Card are done by the off-card Java Virtual Machine all the class files or classes required for an application 
are placed together in one card class file. 

50 

constant_poolQ 

[0158] The constant _pool is a table of variable-length structures () representing various string constants, class 
names, field names, and other constants that are refenred to within the CardClassFile structure and its substnictures. 
ss [01 59] The first entry in the card class file is constantj}ool[0]. 

[0160] Each of the constant_pool table entries at indices 0 through const.size Is a variable-length structure (). 
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classO 



[0161] The class is a table of max.class classes that constitute the application loaded onto the card. 



5 



Constant Pool 



[0162] All constant j30ol table entries have the following general fomiat: 



1$ 



10 



Cplnfo { 
u1 tag; 
u1 InfoQ; 

} 



[0163] Each item in the constant _pool table must begin with a 1-byte tag indicating the kind of cpjnfo entry. The 
contents of the info an^ay varies with the value of tag. The valid tags and their values are the same as those specified 
in the Red book. 

20 [0164] Each tag byte must be followed by two or more bytes giving infomnatlon about the specific constant. The 
fonnat of the additional Information varies with the tag value. Currently the only tags that need to be Included are 
CONSTANT^CIass, CONSTANT„FleldRef. CONSTANT_MethodRef and CONSTANTJnterfaceRef. Support for other 
tags be added as they are Included in the specification. 
CONSTANT^CIass 

25 [0165] The CONSTANT_ClassJnfo structure is used to represent a class or an interface: 



[01 67] The tag item has the value CONSTANT^CIass (7). 

40 

namejndex 

[0168] The value of the name_index item must represent a valid Java class name. The Java class name represented 
by namejndex must be exactly the same Java class name that is described by the corresponding CONSTANT.CIass 
45 entry in the constant_pool of the original class file. 

CONSTANT_Fieldref, CONSTANT_Methodref, and CONSTANT_lnterfaceMethodref Fields, methods, and interface 
methods are represented by similar structures: 



30 



CONSTANT^CIasslnfo { 
u1 tag; 

u2 namejndex; 

} 



35 [01 66] The items of the CONSTANT^CIassJnfo structure are the following: 



tag 



55 



50 



CONSTANT.Fieldreflnfo { 
u1 tag; 

u2 classjndex; 
u2 name^sig Jndex; 

> 
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CONSTANT.Methodreflnfo { 

5 u1 tag; 

u2 class Jndex; 
u2 name.slgjndex; 

) 

"* CONSTANTJnterfaceMethodreflnfo{ 

u1 tag; 

u2 dassjndex; 
u2 namejsigjndex; 

} 

[0169] The items of these structures are as follows: 

20 

tag 

[0170] The tag item of a CONSTANT.FIeldreflnfo structure has the value CONSTANT.Fieldref (9). 
[0171] The tag item of a CONSTANT.Methodreflnfo structure has the value CONSTANT.Methodref (1 0). 
25 [0172] The tag item of a CONSTANT_lnterfaceMethodrefinfo structure has the value 
CONSTANT.InterfaceMethodref (11). 

classsjndex 

30 [01 73] The value of the class.index Item must represent a valid Java class or interface name. The name represented 
by class.lndex must be exactly the same name that Is described by the corresponding CONSTANT.CIass^lnfo entry 
in the constant _pool of the original class file. 

name_sig_index 

35 

[0174] The value of the name_sigjndex item must represent a valid Java name and type. The name and type rep- 
resented by name.sigjndex must be exactly the same name and type described by the 
CONSTAIfr_NameAndType_info entry In the constant_pool structure of the original class file. 

40 Class 

[0175] Each class is described by a fixed-length Classlnfo structure. The fonmat of this structure is: 

45 Classlnfo { 

u2 name Jndex; 
u1 max_flelcl; 
u1 max sfield; 

50 ^ 



55 
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u1 max_method; 
u1 maxjnterface; 
^ u2 superclass; 

u2 access^flags; 

Reldlnfo field[max_field+max_sfleld]; 
10 Interfacelnfo interface[maxjnterfacej; 

Methodinfo method[max_method]; 

} 

15 [0176] The items of the Classinfo structure are as follows; 
namejndex 

[01 77] The value of the name_index Item must represent a valid Java class name. The Java class name represented 
20 by namejndex must be exactly the same Java class name that Is described in the corresponding CtassFile structure 
of the original class file. 

max.field 

25 [0178] The value of the max_field item gives the number of Fieldlnfo () structures in the field table that represent the 
instance variables, declared by this class or interface type. This value refers to the number of non-static the fields (n 
the card class file. If the class represents an interface the value of maxjield is 0. 

max.sfield 

30 

[0179] The value of the max_sfleld item gives the number of Fieldlnfo structures in the field table that represent the 
class variables, declared by this class or interface type. This value refers to the number of static the fields in the card 
class file. 

35 max_method 

[0180] The value of the max_method item gives the number of Methodinfo () structures in the method table, 
max.interface 

40 

[01 81 ] The value of the maxjnterface item gives the number of direct superinterf aces of this class or interface type, 
superclass 

45 [01 82] For a class, the value of the superclass item must represent a valid Java class name. The Java class name 
represented by superclass must be exactly the same Java class name that is described in the con-esponding ClassFile 
structure of the original class file. Neither the superclass nor any of its superclasses may be a final class. 
[0183] If the value of superclass Is 0, then this class must represent the class java.lang.Object, the only class or 
interface without a superclass. 

50 [0184] For an interface, the value of superclass must always represent the Java class java.lang.Object. 

accessjiags 

[0185] The value of the accessjiags item is a mask of modifiers used with class and interface declarations. The 
55 accessjiags modifiers and their values are the same as the accessjiags modifiers in the corresponding ClassFile 
structure of the original dass file 
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fieldQ 

[0186] Each value In the field table must be a fixed-length Fteldlnfo () structure giving a complete description of a 
field in the class or Interface type. The field table Includes only those fields that are declared by this class or Interface. 
5 It does not include items representing fields that are inherited from superclasses or superinterfaces. 

interfaceO 

[0187] Each value in the interface array must represent a valid interface name. The interface name represented by 
10 each entry must be exactly the same Interface name that Is described in the corresponding Interface array of the original 
class file. 

methodQ 

15 [01 88] Each value in the method table must be a variable-length Methodinf o () structure giving a complete description 
of and Java Virtual Machine code for a method in the class or interface. 

[01 89] The Methodinfo structures represent all methods, both instance methods and, for classes, class (static) meth- 
ods, declared by this class or interface type. The method table only includes those methods that are explicitly declared 
by this class. Interfaces have only the single method <cllnit>, the interface initialization method. The methods table 
20 does not Include items representing methods that are inherited from superclasses or superinterfaces. 

Fields 

[0190] Each field is described by a fixed-length fieldjnfo structure. The fomnat of this structure Is 

25 

Fleldlnfo{ 
u2 namejndex; 
30 u2 signaturejndex; 

u2 access.flags; 

) 

35 [0191] The Items of the Fleldlnfo structure are as follows: 
name.index 

[0192] The value of the namejndex item must represent a valid Java field name. The Java field name represented 
40 by namejndex must be exactly the same Java field name that Is described in the corresponding fieldjnfo structure 
of the original class file. 

signaturejndex 

45 [01 93] The value of the signature.index item must represent a valid Java field descriptor. The Java field descriptor 
represented by signature Index must be exactly the same Java field descriptor that is described in the corresponding 
fieldjnfo structure of the original class file. 

accessjiags 

50 

[01 94] The value of the access JIags item is a mask of modifiers used to describe access pemnission to and properties 
of a field. The access Jlags modifiers and their values are the same as the access JIags modifiers in the corresponding 
fieldjnfo stnicture of the original class file. 

55 Methods 

[0195] Each method is described by a variable-length Methodinfo structure. The Methodinf o structure is a variable- 
length structure that contains the Java Virtual Machine Instructions and auxiliary infomnation for a single Java method, 
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instance initialization method, or class or interface initialization method. The structure has the following fonmat: 

Methodlnfo { . 
^ u2 namejndex; 

u2 signature Jndex; 
u1 maxjocal; 

10 u1 max_arg; 

u1 max^stack; 
u1 access^flags; 
u2 codejength: 
u2 exception Jength; 
u1 code[codejength]; 
{ u2 startjjc; 

^ u2 endjDc; 

u2 handlerj)c; 
u2 catchjype; 

25 ) elnfo[exceptlonJengthl: 

) 

[0196] The items of the Methodinfo structure are as follows: 

30 

namejndex 

[0197] The value of the name_index item must represent either one off the special internal method names, either 
<init> or <clin]t>, or a valid Java method name. The Java method name represented by namejndex must be exactly 
35 the same Java method name that is described in the con^espondlng methodjnfo structure of the original class file. 

signaturejndex 

[0198] The value of the signature^index item must represent a valid Java method descriptor. 
40 [01 99] The Java method descriptor represented by signaturejndex must be exactly the same Java method descriptor 
that is described in the corresponding methodjnfo structure of the original class file. 

max_local 

45 [0200] The value of the maxjocals Item gives the number of local variables used by this method, excluding the 
parameters passed to the method on invocation. The index of the first local variable is 0. The greatest local variable 
index for a one-word value Is maxjocals- 1. 

max.arg 

50 

[0201] The value of the max_arg item gives the maximum number of arguments to this method, 
max.stack 

55 [0202] The value of the max_stacl< item gives the maximum number of words on the operand stack at any point 
during execution of this method. 
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access.flags 

[0203] The value of the accessj lags item is a mask of modifiers used to descnbe access permission to and properties 
of a method or Instance initialization method. The aocess_flags modifiers and their values are the same as the 
5 accessjlags modifiers in the corresponding methodjnfo structure of the original class file. 

codejength 

[0204] The value of the codejength Item gives the number of bytes In the code array for this method. The value of 
10 codejength must be greater than zero; the code an^ay must not be empty. 

exception Jength 

[0205] The value of the exceptionjength item gives the nunnber of entries in the exception Jnfo table. 

1$ 

codeQ 

[0206] The code array gives the actual bytes of Java Virtual Machine code that Implement the method. When the 

code array Is read into memory on a byte addressable machine if the first byte of the array Is aligned on a 4-byte 
20 boundary, the tableswitch and lookupswitch 32-bit offsets will be 4-byte aligned; refer to the descriptions of those 
instructions for more infomnation on the consequences of code array alignment. 

[0207] The detailed constraints on the contents of the code an-ay are extensive and are the same as described in 
the Java Virtual Machine Specification. 

25 einfo n 

[0208] Each entry in the einfo array describes one exception handler in the code array. Each einfo entry contains 
the following items: 

30 start_pc, end_pc 

[0209] The values of the two items startjDC and end_pc indicate the ranges in the code array at which the exception 
handler is active. 

[0210] The value of start_pc must be a valid index into the code array of the opcode of an instruction. The value of 
35 end_pc either must be a valid Index Into the code array of the opcode of an Instruction, or must be equal to codejength, 
the length of the code array. The value of start_pc must be less than the value of end_pc. 

[0211] The start _pc is inclusive and end_pc is exclusive; that is. the exception handier must be active while the 
program counter is within the Interval [start j3c, endjac]. 

40 handler j)c 

[0212] The value of the handler_pc Item indicates the start of the exception handler. The value of the Item must be 
a valid index into the code array, must be the index of the opcode of an instruction, and must be less than the value 
of the codejength item. 

45 

catch.type 

[0213] If the value of the catch_type item Is nonzero, it must represent a valid Java class type. The Java class type 
represented by catch_type must be exactly the same as the Java class type that is described by the catch Jype in the 
50 con^esponding methodjnfo structure of the original class file. This class must be the class Throwable or one of its 
subclasses. The exception handler will be called only if the thrown exception is an instance of the given class or one 
of its subclasses. 

[0214] If the value of the catch_type item is zero, this exception handler Is called for all exceptions. This is used to 

implement finally. 

55 

Attributes 

[0215] Attributes used In the original class file are either eliminated or regrouped for compaction. 
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[021 6] The predeftned attributes SourceFile, ConstantValue, Exceptions. LineNumberTable. and Local- VariabteTable 
may be eliminated without sacrificing any infomfiatlon require for Java byte code interpretation. 
[0217] The predefined attribute Code which contains all the byte codes for a particular method are moved in the 
corresponding Methodlnfo structure. 

5 

Constraints on Java Card Virtual Machine Code 

[0218] The Java Card Virtual Machine code for a method, Instance initialization method, or class or interface Initial- 
ization method is stored in the array code of the Methodlnfo structure of a card class file. Both the static and the 
10 structural constraints on this code array are the same as those described in the Red book. 
[0219] Limitations of the Java Card Virtual Machine and Java Card class File Fonmat 

[0220] The following limitations in the Java Card Virtual Machine are imposed by this version of the Java Card Virtual 
Machine specification: 

15 The per-card class file constant pool is limited to 65535 entries by the 16-bit const_siz field of the CardClassFlle 

structure Q. This acts as an internal limit on the total complexity of a single card class file. This count also includes 
the entries corresponding to the constant pool of the class hierarchy available to the applicatio in the card. 
The amount of code per method is limited to 65535 bytes by the sizes of the indices in the Methodlnfo structure. 
The number of local variables In a method is limited to 255 by the size of the maxjoca item of the Methodlnfo 

20 structure (), 

The number of fields of a class is limited to 510 by the size of the max^field and the max.sfield items of the 
Ciasslnfo structure (). 

The number of methods of a class is limited to 255 by the size of the max_method iten of the Ciasslnfo structure (). 
The size of an operand stack is limited to 255 words by the max.stack field of the Methodlnfo structure (). 

25 
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30 APPENDIX B 

String To ID Input And Output 

[0222] For the con-ect operation of Card JVM it Is very important that the declared and generated IDs are con-ectly 
35 managed. This management Is controlled by the definitions in the string to ID Input file String-ID INIVIap. This textual 
file, the basis for which is shown below, declares which areas of the namespace can be used for what purposes. One 
possible arrangement of this map may reserve some IDs for intemal use by the Card JVM interpreter, and the rest is 
allocated to Card JVM applications. 

40 
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#String-iO INMapfile. 
# 

# 4000 - 7FFF Available for application use. 

# FOOO - FFFE Reserved for Card JVM's Internal use. 
# 

# The area from FOOO to FFFF Is reserved for 

# Card JVM's internal use. 
# 

# FOOO - Name of the startup class 

# (changes for each application) 

# F001 - Name of the startup method 

# (may change for each application) 
#F002 
#F003 
#F004 
#F005 
#F006 
#F007 
#F008 
#F009 
#F000A 



constantBase FOOO 

MainApplicatlon 
mainOV 



java/lang/Object 
java/lang/String 
<lnlt>OV 
<cnnlt>OV 
IL 

[1 
[C 
CB 
[S 
# 

constantBase FFFO 
L 



# This area is reserved for simple return t^es. 
#FFFO 



V #FFF1 

I #FFF2 

S #FFF3 

C #FFF4 

B # FFF5 

Z #FFF6 
# 

constantBase 4000 # From here on this space Is application dependent 



constantBase 4000 # From here on this space is application dependent. 

[0223] Essentially, all applications which are to be loaded into a smart card are allocated their own IDs within the 
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0x4000 to 0x7FFR This space fs free for each application since no loaded application is permitted to access other 
applications. 

[0224] Care must be taken on managing the IDs for preloaded class libraries. The management of these IDs is helped 
by the (optional) generation of the string to ID output file String-ID OUTMap file. This map is the String-ID INMap 
5 augmented with the new String-ID bindings. These bindings may be produced when the Card Class File Converter 
application terminates. The String-ID OUTMap is generated for support libraries and OS interfaces loaded on the card. 
This map may be used as the String-ID INMap for smart card applications using the support libraries and OS interfaces 
loaded on the card. When building new applications this file can generally be discarded. 

[0225] As an example consider the following Java program. HelloSmartCard.Java. When compiled it generates a 
10 class file HelloSmartCard.cIass. This class file has embedded in it strings that represent the class name, methods and 
type information. On the basis of the String-ID INMap described above Card Class File Converter generates a card 
class file that replaces the strings present in the class file with IDs allocated by Card Class File Converter. Table 1 lists 
the strings found in the constant pool of HelloSmartCard.cIass with their respective Card Class File Converter assigned 
IDs. Note that some strings (like "java/tang/Object") have a pre-assigned value (F002) and some strings (like "OV") 
IS get a new value (4004). 

[0226] Program : HelloSmartCard.java 



public class HelloSmartCard { 
public byte aVarlable; 

public static void main() { 
HeKoSmartCard h = new HelloSmaitCardO; 
h,aVariable = (byte)13; 

) 

) 

Relevant entries of String-ID OUTMap 
APPENDiXC 

35 

Byte codes supported by the Card JVI\^ in the preferred embodiment 
[0227] 
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AALOAD 


AASTORE 


ACONST.NULL 


ALOAD 


ALOAD.O 


ALOAD^I 


AL0AD_2 


AL0AD_3 


ARETURN 


ARRAYLENGTH 


ASTORE 


ASTORE.O 


ASTORE^I 


AST0RE^2 


AST0RE_3 


ATHROW 


BALOAD 


BASTORE 


CHECKCAST 


DUP 


DUP2 


DUP2_X1 


DUP2_X2 


DUP^XI 


DUP_X2 


GETFIELD 


GETSTATIC 


GOTO 


lADD 


lALOAD 


lAND 


lASTORE 


1CONST_0 


ICONST^I 


IC0NST_2 


IC0NST_3 


ICONST_4 


IC0NST_5 


ICONST.MI 


IDIV 


IFEQ 


IFGE 


IFGT 


IFLE 


IFLT 


IFNE 


IFNONNULL 


IFNULL 



25 
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(continued) 





IP ACMPPO 


IF ACMPNE 


IF ICMPEQ 




IF ICMPGE 


IF ICMPGT 

1 1 1 IVI f ^a* 1 


IFJCMPLE 


9 


IFJCMPLT 


IFJCMPNE 


iINC 




ILOAD 


ILOAD_0 


ILOAD^i 




IL0AD_2 


IL0AD_3 


IMUL 




INEG 


INSTANCED F 


INT2BYTE 




INT2CHAR 


INT2SHORT 


INVOKEINTERFACE 


10 


INVOKENONVIRnrUAL 

II 1 V X^IX^I ^^yi^ Villi \J 


INVOKESTATIC 


INVOKE VIRTUAL 

II ^ ▼ \ w villi 




lOR 


IREM 


IRETURN 




ISHL 


ISHR 


ISTORE 




ISTORE_0 


ISTOREJ 


IST0RE_2 


15 


ISTORE^3 


ISUB 


lUSHR 




IXOR 


JSR 


LDC1 




LDC2 


LOOKUPSWITCH 


NEW 




NEWARRAY 


NOP 


POP 




POP2 


PUTFIELD 


PUTSTATIC 


20 


RET 


RETURN 


SALOAD 




SASTORE 


SIPUSH 


SWAP 




TABLESWrrCH 


BIPUSH 





25 Standard Java byte codes numbers for the byte codes supported In the preferred embodiment 
[0228] package util; 
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r 

* List of actual Java Bytecodes handfed by this JVM 

* ref. Lindoiitm and Yellin. 

* Copyright (c) 1996 Schiumberger Austin Products Center. 

* Schiumberger, Austin, Texas. USA. 
•/ 

public Interface BytecodeDefn { 

public static final byte 'UiOP ~ (byte)0; 
' pubfic static final byte ACONST,NULL » (byte)1,- 

public static final byte tC0NST.M1 - (byte)2; 

public static final byte ICONST.O - (byte)3; 

public static final byte IC0NST.1 = (byte)4: 

public static final byte IC0NST.2 = (byte)5; 

public static final byte IC0NST,3 « (byte)8: 

public static final byte IC0NST,4 « (byte)7; 

public static final byte IC0NST_5 = (byte)8; 

public static final byte BIPUSH > (byte)16; 

public static final byte SIPUSH = (byte)1 7; 

public static final byte LDC1 s (byte)1 8; 

public static final byte LDC2 s (byte)19; 

public static final byte ILOAO » (byte)21; 

public static final byte ALOAD = (byte)25; 

public static final byte ILOAD^O - (byte)26: 

public static final byte ILOAD J « (byte)27: 

public static final byte IL0AD_2 « (byte)28; 

public static final byte ILOAD_3 - (byte)29; 

pubKc static final byte ALOAO_0 = (byte)42; 

public static final byte AL0A0.1 (byte)43: 
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public Static final byte AL0AD_2 - (byte)44; 
public static final byte AL0AD_3 - (byte)45: 
public static final byte lALOAD - (byte)46; 
public static final byte AALOAD s (byte)50; 
public static final byte BALOAD ~ (byte)51; 
public static final byte CALOAO - (byte)52; 
public static final byte ISTORE = (byte)54: 
public static final byte ASTORE = (byte)58; 
public static final byte ISTORE_0 = (byte)59: 
public static final byte ISTOREJ = (byte)60: 
public static final byte IST0RE_2 = (byte)61: 
public static final byte IST0RE_3 = (byte)62: 
public static final byte ASTORE_0 = (byte)75: 
public static final byte AST0RE_1 = (byte)76; 
public static final byte AST0RE.2 « (byte)77; 
public static final byte AST0RE.3 s (byte)78; 
public static final byte lASTORE = (byte)79; 
public static final byte AASTORE « (byte)83; 
public static final byte BASTORE » (byte)84; 
public static final byte CASTORE « (byte)85: 
public static final byte POP = (byte)87: 
public static final byte P0P2 - (byte)88; 
public static final byte DUP s (byte)69; 
public static final byte DUP_X1 » (byte)gO: 
public static final byte DUP_X2 = (byte}91; 
public static final byte DUP2 « (byte)92; 
public static final byte DUP2JC1 = (byte)93; 
public static final byte DUP2_X2 = {byte)94; 
public static final byte SWAP = (byte)95; 
public static final byte lADD - (byte)96; 
public static final byte ISUB s (byte)100: 
public static final byte IMUL » (byte) 104; 
public static final byte lOIV & (byte)108; 
public static final byte IREM « (byte)112; 
public static final byte INE6 = (byte)1 16; 
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public static final byte ISHL s (byte)120: 
public static final byte ISHR - (byte)122: 
public static final byte iUSHR - (byte)i24; 
public static final byte lAND » (byte)126; 
public static final byte lOR » (byte)128.' 
public static final byte (XOR » (byte}130: 
public static final byte lINC = (byte)132: 
public static final byte INT2BYrE * (byte)145; 
public static final byte INT2CHAR = (byte)146; 
public static final byte INT2SH0RT = (byte)147; 
public static final byte IFEQ = (byte)153: 
public static final byte IFNE = (byte)154: 
public static final byte IFLT ' (byte) 155; 
public static final byte IFGE ^ (byte)156; 
public static final byte IFGT - (byte)157; 
public static final byte IFLE - (byte)158.- 
public static final byte IFJCMPEQ ^ (byte)159: 
pubnc static final byte IFJCMPNE = (byte)160: 
public static final byte IFJCMPLT - (byte)161; 
public static final byte IF^ICMPGE = (byte)162; 
public staUc final byte IFJCMPGT = (byte)163: 
public static final byte IFJCMPLE s (byte)164.- 
public static final byte IF.ACMPEQ = (byte)165: 
public static final byte IF.ACMPNE - (byte)166; 
public static final byte GOTO » (byte)167; 
public static final byteLJSR » (byte}168; 
public static final byte RET ~ (byte) 169; 
public static final byte TABLESWITCH « (byte)170; 
public static final byte LOOKUPSWITCH = (byte)171; 
public static final byte IRETURN « (byte)172; 
public static final byte ARETURN » (byte)176; 
public static final byte RETURN « (byte)177: 
public static final byte GETSTATIC ^ (byte)178: 
public static final byte PUTSTATIC = (byte)179: 
public static final byte GETFIELO « (byte)180: 
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public Static final byte PUTFIELD - (byte)181; 
public static final byte INVOKEVIRTUAL - (byte)182: 
public static final byte INVOKENONVIRTUAL » (byte)183; 
public static final byte INVOKESTATIC - (byte)184: 
public static final byte INVOKEINTERFACE - (byte)185; 
public static final byte NEW = (byte)187: 
public static final byte NEWARRAY » (byte)188; 
public static final byte ARRAYLENGTH « (byte)190: 
public static final byte ATHROW = (byte)191 ; 
public static final byte CHECKCAST = (byte)192: 
public static final byte INSTANCEOF = (byte)193; 
public static final byte IFNULL - (byte)198; 
public static final byte IFNONNULL - (byte)199; 
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APPENDIX D 

Card Class File Converter byte code conversion process 
[0229] 

r 

* Reprocess code block. 
V 

static 
void 

reprocessMethod(iMethod* imeth) 
{ 

int pc; 
int npc; 
int align; 
bytecode* code; 
int codelen; 
Int i; 

int opad; 
int npad; 
int ape; 
int high; 
int low; 

r codeinfo is a table that keeps track of the valid Java bytecodes and their 

* corresponding translation 

V 

code = imeth->extemal->code; 
codelen = imeth->extemal->codeJength; 

jumpPos = 0; 
align s 0; 

Scan for unsupported opcodes V 

for (pc = 0; pc < codelen; pc = npc) { 
if (codeinfo[code[pc]l.valid 0) { 
errorf Unsupported opcode %d", code[pcl); 
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) 

npc - nextPC(pc, code); 

} 

/* Scan for jump instructions an insert into jump table */ 

for (pc = 0; pc < codelen; pc = npc) { 
npc = nextPC(pc, code); 

if (codeinfo[code[pc]].valid 3) { 
insertJump(p&M, pc, (int16)((codefpc+1J « 8)|codeIpc+2J)); 

) 

else if (codeinfo[code(pc)].va(id 4) { 
ape s pc & •4; 

low= (code[apc+8J « 24) | (code[apc+9I « 16) 

I (code(apc+10] « 8) | codelapc+11J: 
high = (codeIapc+121 « 24) | (code[apc+13) « 16) 

I (code[apc-i-14] « 8) | codelapc+IS]; 
for (I « 0; l< high-low+1; I++) { 
insertJump(apc+(i*4)+18, pc, 

(lnt16){(codeIapc4(l*4)+18} « 8) | codeIapc+{i*4)+19))); 

} 

insertJump(apc+6, pc, (int16)((code(apc+6J « 8) | code[apc+7])); 

) 

else if (codeinfo[code[pc]].valtd ~ 5) { 
ape B pc & -4; 

low a (code[ap&f-8] « 24) | (code[apc4-9] « 16) 

I (code(apc+10J « 8) | code[apc+11J; 
for (i = 0; i < low; i++) { 
insertJump(apc+(i*8)+18, pc, 

(int16)((codelapc+(i'8)+18) « 8) | codelapc+(i*8)+19])); 

) 

insertJump(apc^. pc. (tnt16)((code[apc^] « 8) | codefapc+T])); 

) 

) 
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#lfdef TRANSLATE.BYTECODE . 
r Translate specific opcodes to general 

for (pc =s 0; pc < codelen; pc = npc) { 
r This is a translation code V 
If (codeinfo[ccxJelpcI]. valid == 2) { 

switch (code[pc]) { 

case ILOAD^O: 

case IL0AD_1; 

case IL0A0_2: 

case ILOAD_3: 

insertSpaceCcode, &codelen, pc, 1); 
align 1; 

codeIpc+1J = codefpc] - ILOAD^O; 

code[p&fO] = ILOAD; 

break; 

case ALOAD_0: 
case ALOAD_1: 
case ALOA0_2: 
case ALOA0_3: 

lnsertSpace(code, &codeien, pc, 1); 
align += 1; 

code[pc+1] = code[pc] - ALOAD^O; 

code[pc+OJ s ALOAD: 

break; 

case 1STORE_0: 
case ISTOREJ: 
case ISTORE_2: 
case IST0RE_3: 

insertSpace(code, &codelen, pc, 1); 
align += 1; 

codeft>c+1J = code[pcJ - ISTORE_0; 
code(pc+01 = ISTORE; 
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break; 

case ASTORE_0: 
case ASTOREJ; 
caseAST0RE_2: 
case AST0RE_3: 

lnsertSpace(code, &codelen. pc. 1): 
align 1; 

codelpc+l] = code[pc] - ASTORE^O: 

code[pc-<'0] = ASTORE; 

break; 

case ICONST^MI: 

insertSpace(code, &codelen, pc, 2); 

align += 2; 
• codeIpc+2J = 255; 

codelpc+1] = 255; 

code(pc+01 = SIPUSH; 

break; 

case ICONST.0: 
case ICONSTJ: 
case ICONST_2: 
case IC0NST_3: 
case ICONST4: 
case IC0NST_5: 

ir)sertSpace(code, &codelen, pc. 2); 
align +» 2; 

code[pc-'-2] s code[pc] • ICONSTJ); 
codefpc+1J = 0; 
code[pc+0]=sSIPUSH; 
break; 

case LDC1: 

insertSpace(code. &codelen. pc, 1); 
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align 1; 
code[pc-<-1] = 0; 
code[pc+0} = LDC2; 
break; 
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case BIPUSH: 

insertSpace(code, &codeien, pc» 1); 
align +=1: 

lf((lnt8)code[pc+2] >=0){ 
code[pc-t-1] = 0; 

) 

else{ 

code[pc+1] = 255; 

} 

codelpc+OJ = SIPUSH: 
break; 

case INT2SHORT: 
removeSpace(code. &codeien, pc. 1); 
align 1; 
npc = pc; 
continue; 

) 

} 

else if (codeinfo[code[pc]].valid == 4 1| codeinfo(code[pc]].valid == 5) { 
r Switches are aligned to 4 byte boundaries. Since we are inserting and 

* removing bytecodes, this may change the alignment of switch instnictlons. 

* Therefore, we must readjust the padding in switches to compensate. 
V 

opad = (4 - (((pc+1) - align) % 4)) % 4; r Current switch padding V 
npad = (4 - ((pc+1) % 4)) % 4; * /* New switch padding V 
if (npad > opad) { 

insertSpdce(code» &codelen, pc+1, npad • opad); 
align += (npad - opad); 

} 

else if (npad < opad) { 

removeSpace(code, &codeien» pc+1, opad - npad); 
align ~ (opad - npad); 

) 



35 



EP0932 865B1 



} 

npc= nextPC(pc, code); 

} 

#endif 



r Relink constants V 

for (pc - 0; pc < codelen; pc ^ npc) { 

npc = nextPC(pc, code); 

i = (ulnt16)((code[pc+1J « 8) + Gode[pc+21); 

switch (code[pc]) { 
case LDC2: 
/* T == general Index V 
switch (cltem(O.type) { 
case CONSTANTJnteger: 
I = cltem(i).v.tjnt; 
code[pc]»SIPUSH; 
break; 

case CONSTANT^String: 
i = buildStringlndex(i); 
break; 

default 

errorf Unsupported loading of constant type"*); 
break; 

} 

break; 

case NEW: 
case INSTANCEOF: 
case CHECKCAST: 
/• T== class Index*/ 
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i s buildClasslndex(i); 
break; 

case GETFIELD: 
case PUTFIELD: 

r 7 =s field index*/ 

/* i = buildReldSignatureindex(i); */ 

i = buildStaticFieldSignatureindex(i); 

break; 

case 6ETSTAT1C: 
case PUTSTATIC: 

r T == field index •/ 

i = bui(dStaticFieldSignaturelndex(0: 

break; 

case INVOKEVIRTUAL: 
case INVOKENONVIRTUAL: 
case INVOKESTATIC: 
case INVOKEINTERFACE: 

r 'i' == method signature index V 

\ B buiIdSignaturelndex(i}; 

break; 

} 

r Insert application constant reference V 
codelpc+1] = (i » 8) & OxFF; 
code[pc+2I - 1 & OxFF; 

} 



#ifdef I^ODIFY.BYTECODE 
I* Translate codes */ 
for (pc = 0; pc < codelen; pc = npc) { 
npc a nextPC(pc, code); 
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code[pc] » codeinfo[code[pc]].translation; 

} 

#endif 



/* Relink Jumps V 

for (I = 0; I < jumpPos; { 

ape s jumpTable[ilat; 

pc = jumpTablefiJ.from; 

npc ^ jumpTab!e[l].to - pc; 

code[apc+0] = (npc » 8) & OxFF; 
code[apc+l] - npc & OxFF; 

} 

r Fixup length V 

imeth->extemal->codeJength = codelen; 
imeth->esize = (SIZEOFMETHOD + codelen + 3) & -4; 

} 
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APPENDIX E 

Example Loading And Execution Control Program 
[0230] 

public class Bootstrap! 

// Constants used throughout the program 
static final byte BUFFER_LENGTH = 32; 
static final byte ACK_SIZE = (byte)1 ; 

static final byte ACK_CODE = (byte)O; 

static final byte OS_HEADER_SIZE = (byte)OxlO; 
static final byte GPOS.CREATE^FILE = (byte)OxEO: 

static final byte STJNVALID.CLASS » (byte)OxCO: 
static final byte STJNVALID^PARAMETER « (byte)OxAO: 
static final byte STJNS_NOT_SUPPORTED = (byte)OxBO; 
static final byte ST_SUCCESS » (byte)OxOO; 

static final byte ISO_COMMAND_LENGTH = (byte)5; 
static final byte ISO_READ_BINARY = (byte)OxBO: 
staUc final byte ISO_UPDATE_BINARY = (byte)0xD6: 
static final byte ISOJNIT_APPLICATION = (byte)0xF2; 
static final byte ISO.VERIFY^KEY = (byte)0x2A: 
static final byte ISO_SELECT_FILE = (byte)0xA4; 

static final byte ISO_CLASS « (byte)OxCO; 

static final byte ISO_APP_CLASS « (byte)0xFO; 



public static void main 0 { 

byte pbufferQ ^ new byte[ISO.COMMAND_LENGTH]: 
byte dbufferQ = new byte[BUFFER.LENGTH]; 
byte ackByteQ » new byte[ACK_SIZEI; 
//short fileld; 
short offset; 
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byte bRetumStatus; 

// Initialize Communications 
_OS.SenclATR0: 

do{ 

// Retrieve the command header 

_0S.6etMessage(pbuffer. ISO_COMMAND_LENGTH, ACK.CODE); 

// Verify class of the message - Only ISO Application 
If ((pbufferlO] N ISO_APP_CLASS) 
&& (pbufferlO] != ISO_CLASS)) { 
_0S.SendStatu8(STJNVALID_CLASS); 

} 

etse{ 

// go through the switch 

// Send the acknowledge code 

//Verity if data length too large 
If (pbuffer(4] > BUFFER.LENG7H) { 
bRetumStatus = STJNVALID^P/VRAMETER; 

} 

else 
{ 

switch (pbuffer[1]) { 
case ISO_SELECT.FILE: 

// we always assume that length Is 2 

if(pbuffeif4]!s2){ 

bRetumStatus = STJNVALID.PARAMETER; 

) 

else 
{ 

// get the flleld(offset) in the data buffer 
_OS.GetMessage(dbuffer, (byte)2. pbuffer[1]): 
II cast dbufrer[0..l] into a short 
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Offset - (short) ((dbufferfO] « 8) ( (dbuffer[1] & OxOOFF)); 
bReturnStatus ~ _OS.SelectFile(offset); 

} 

break; 

case ISO_VERIFY_KEY: 
// Gel the Key from the terminal 
_OS.GetMessage(dbuffer, pbuffer[4], pbufferJIJ); 

bReturnStatus = _0S.VerlfyKey(pbufferI3I. 
dbuffer, 
pbuffer[4]): 

break; 

case IS0_IN1T.APPLICATI0N: 
// Should send the id of a valid program file 
_OS.GetMessage(dbuffer, (byte}1, pbufferfl]); 
// compute fiield(offset) from pbuffer[2..3] via casting 
offset = (short) ((pbuffer{2J « 8) ) (pbufferlSJ & OxOOFF)); 
bReturnStatus s __OS.Execute(offeet, 
dbuffer[0)): 

break; 

case GPOS_CREATE_FILE: 
if (pbufferI4] N OS_HEADER_SIZE) { 
bReturnStatus = STJhA^ALID.PARAMETER; 
break; 

> 

// Receive The data 

_OS.GetMessage(dbuffer, pbuffier{4], pbuffertl]); 
bReturnStatus - _OS.CreateRle(dbuffer): 
break; 

case ISO^UPDATE^BINARY: 
_OS.GetMessage(dbuffer. pbuffer[4], pbuffer(1J); 
// compute offeet from pbuffer[2..3] via casting 
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Offset = (short) ((pbuffer(2I « 8) | (pbufferl3] & OxOOFF)): 
// assumes that a file is alfeady selected 
bRetumStatus - _OS.WrlteBinaryRle (offset. 

pbuffer(4], 

dbuffer); 

break; 

case ISO^READ^BINARY: 
// compute afket from pbuffer{2..3] via casting 
offset = (short) ((pbufferI2] « 8) | (pbuffer[3J & OxOOFF)); 
// assumes that a file is already selected 
bRetumStatus - ^OS.ReadBlnaryFile (offset, 

pbufferI4]. 
dbuffer); 
// Send the data if successful 
ackByte[0] - pbuffer[1]; 
if (bRetumStatus =« ST_SUCCESS) { 
_OS.SendMessage(ackByte, ACK_SIZE); 
_OS.SendMessage(dbuffer, pbuffer(4]); 

} " 
break; 

default: 

bRetumStatus = ST.INS_NOT_SUPPORTED; 

) 

} 

_OS.SendStatus(bRetumStatus); 

} 

> 

while (true); 

) 

} 

APPENDIX F 

Methods For Accessing Card Operating System Capabilities in The Preferred Embodiment 

[0231 ] public class _OS { 
static native byte SelectFtle (short filejd); 
static native byte SelectParent Q; 
static native byte SelectCD 0; 
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static native byte SelectRoot 0; 

static native byte CreateFile (byte fife_hdiQ); 

static native byte DeleteFile (short filejd); 

// General File Manipulation 

static native byte ResetFile (); 

static native byte ReadByte (byte offset); 

static native short ReadWord (byte offset); 

// Header IVIanipulation 

static native byte GetFilelnfo (bytefile.hdrO): 

// Binary File support 

static native byte ReadBinaryFile (short offset, 
byte datajength, 
byte bufferO); 

static native byte WriteBinaryFile (short offset, 

byte datajength, 

byte bufferO); 

// Record File support 

static native byte SetectRecord (byte record_nb, 
byte mode); 

static native byte NextRecord (); 
static native byte PreviousRecord (); 
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Static native byte ReadRecord (byte record^dataQ, 

byte record_nb» 

byte offset, 

byte length); 

static native byte WriteRecord (byte bufferQ, 

byte record^nb, 

byte offset, 

byte length): 



//Cyclic File Support 

static native byte LastUpdatedRec Q; 



II Messaging Functions 



static native byte 

static native byte 
static native byte 



GetMessage (byte bufferfl, 
byte expectedjength, 
byte ack_code); 

SendlVlessage (byte buffeifj, 
byte datajength): 

SetSpeed (byte speed); 



// Identity Management 



static native byte 
static native byte 



static native byte 



static native byte 



CheckAccess (byte ac_actlon); 
VerifyKey (byte l<ey_number, 

byte lcey_buffert], 

byte keyjength); 
VerifyCHV (byte CHV^number. 

byte CHV^bufferfl. 

byte unblock Jlag); 
ModilyCHV (byte CHV^number, 

byte old^CHV^bufferfl, 

byte new_CfW_bufferO, 

byte unblockjlag); 
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Static native byte 
static native byte 

static native byte 
static native byte 

static native byte 
static native byte 



GetFtleStatus 
SetFileStatus 



(): 

(byte fite_status); 



GrantSupervisorMode (); 
RevokeSupervisorModeO; 



SetFiieACL 
GetFileACL 



// File context manipulation 
static native void InitFileStatus 



static native void 
static native void 



(byte file_aclO); 
(byte file_aclD); 



0; 



BackupFiteStatus (}; 
RastoreFileStatus (); 



// Utilities 
static native byte 



static native short 
static native void 
static native byte 
static native byte 

static native byte 



CompareBuffer (byte pattemjeng 

byte buffeMQ, 

byte buffer_2D): 
AvaiiableMemory (); 
ResetCard (byte mode); 
SendATR (); 
SetDefaultATR (byte bufferfl, 

byte length); 
Execute (short fiiejd, 

byte flag); 



// Global state variable functions 



static native byte 
static native byte 
static native short 
static native byte 
static native byte 
static native short 



Getldentity 0: 
GetRecordNb (); 
GetApplicationId (); 
GetRecordLength 0; 
GetFileType 0; 
GetFtleLength 0; 



static native void SendStatus (byte status); 
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APPENDIX G 

Byte Code Attributes Tables 

5 Dividing Java byte codes into type groups 

[0232] Each bytecode Is assigned a 5 bit type associated with It. This is used to group the codes Into similarly behaving 
sets. In general this behaviour reflects how the types of byte codes operate on the stack, but types 0, 13, 14, and 15 
reflect specific kinds of instructions as denoted in the comments section. 
10 [0233] The table below illustrates the state of the stack before and after each type of instruction Is executed. 



IS 



20 



25 



30 



Type 


Before execution 


After exececutlon 


Comment 


0 






Illegal instruction 


1 


stkO==int stk1==lnt 


pop(1) 




2 


stkO==int 


pop(1) 




3 
4 


stkO==int stk1==lnt 


pop(2) 




5 


push(1) 






6 


stkO==lnt stk1==lnt 


pop(3) 




7 


stkO==int 


pop(1) 




8 


stkO==ref 


pop(1) 




9 


stkO==int 


pop{1) 




10 


push(1) 


stkO<-int 




11 


push{1) 


stkO<-ref 




12 


stkO==ref 


stkO<Hnt 




13 






DUPs, SWAP instructions 


14 






INVOKE Instructions 


15 






FIELDS Instructions 


16 




stkO<-ref 
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Using Standard Java Byte Code (without reordering) • Attribute Lookup Table 
[0234] 



r 

* Table of bytecode decode information. Tiiis contains a bytecode t^e 

* and a bytecode length. We currently support all standard bytecodes 

* (le. no quicks) which gives us codes 0 to 201 (202 codes in all). 
V 



#define 


T. 


0 


#define 


T3 


1 




Tfi 


2 


#define 


T1 


3 


#ciefine 


T2 


4 


#clefine 


T7 


5 


#define 


T9 


6 


#define 


T8 


7 


#define 


T12 


8 


#define 


T10 


9 


#clefine 


T5 


10 


#define 


Til 


11 


#define 


Tie 


12 


#define 


T4 


13 


#define 


T13 


14 


#define 


T14 


15 


#define 


T15 


16 



#define DfT.L) 

_BUILDJTYPE_ANDJLENGTH(T. L) 

#deflne _BUILDJTYPE_ANDJLENGTH(T,L) 

LBUILDJTYPE(T)LBUILDJLENGTH(L)) 

#define _BUILDJTYPE(T) ((T) « 3) 

#define _BUILDJLENGTH(I.) (L) 

#define _GETJTYPE(I) ((l)&0xF8) 

#define _GETJLENGTH(I) ((I) & 0x07) 
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const uint8 _SCODE _decodeinfoI25q = { 



D{T4 , 1 ), 


r NOP 


/ 


D(T11 . 1 ), 


r ACONST_NULL 


V 


D(T10. 1 ), 


r ICONST^MI 


/ 


D(T10. 1 ). 


r ICONST_0 


•/ 


D{T10, 1 ). 


r IC0NST_1 


•/ 


D(T10,1). 


r IC0NST_2 


V 


D(T10,1 ). 


r ICONST_3 


V 


D(T10.1 ). 


r IC0NST_4 


*/ 


D(TIO.I). 


r ICONST_5 


V 


D(T_ ,1). 






D(T_ .1), 






D(T_ .1). 






D(T_ .1). 






D(T_ .1). 






D(T_ .1). 






D(T. .1). 






D(T10.2), 


r BIPUSH 7 




D(T10.3). 


/• SIPUSH V 




D(T_ .2). 


/•LDC1 


V 


D( T11 .3), 


/•LDC2 


*/ 


D(T. .3). 






D(T5 .2). 


/• (LOAD V 




D(T_ .2). 






D(T_ ,2). 






D(T_ .2). 






D(T5 ,2). 


/•ALOAD •/ 




D(T6 .1). 


riLOAD.O V 




D(T5 .1), 


riLOADJ V 




D(T5 .1). 


/*IL0AD_2 •/ 




D(T5 .1). 


/•IL0AD_3 V 




D(T_ .1). 






D(T. .1). 






D(T_ .1). 






D(T_ .1). 
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5 


D(T. .1), 








D{T .1), 








D(T .1), 






10 


D(T .1), 






0(T .1), 








D(T .1). 








D(T .1). 






15 


D( T_ , 1 ), 








D(T5 ,1). 


rALOAD_0 •/ 






D( T5 ,1 ). 


/•AL0AD_1 •/ 




20 


D( T5 ,1 ). 


TALOAD 2 V 






Df T5 ,1 ). 


TALOAD 3 •/ 






D(T .1). 


r lALOAD 7 






D(T .1). 






25 


D(T .1). 








D( T .1). 










r AALOAD */ 




30 


Df T7 .11 


/* BALOAD V 






Df T .11 


r CALOAD */ 






Df T7 .11 


/* SALOAD */ 




3$ 




r (STORE V 






D(T .2). 








D( T , 2 ), 








D( T_ , 2 ), 






40 


D(T8 ,2), 


/•ASTORE V 






D(T2 ,1). 


/* ISTORE.O 


V 




D(T2 .1), 


/• IST0RE_1 


V 


45 


DfT2 1) 


/•ISTORE 2 


9 




D(T2 .1). 


/• !ST0RE_3 


V 




D(T_.1). 






50 


D(T_.1). 








D(T_ .1). 








D(T_ .1). 








D(T_ .1), 






55 


D(T_ ,1). 
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D(T_ .1). 






5 


D(T_ .1), 








D(T_ .1), 








D(T_ .1). 






10 


D(T_ .1), 








D(T_ .1). 








D(T8 .1). 


/•ASTORE^O 


V 


15 


D(T8 ,1). 


/•ASTOREJ 


•/ 




D(T8 .1), 


/•AST0RE_2 


V 




D(T8 ,1). 


/•AST0RE.3 


•/ 




D(T_ ,1), 


riASTORE •/ 




SO 


D(T_ ,1). 








D(T_ . 1 ). 








D(T_ . 1 ), 






25 


D( T. . 1 ). 


/•AASTORE 


'/ 




D(Te .1). 


r BASTORE 


V 




D(T_ ,1). 


rCASTORE 


•/ 


30 


D(T6 .1). 


r SASTORE 


V 


D(T2 ,1). 


rpop 


•/ 




D(T3 .1), 


rp0P2 


•/ 




D(T13,1). 


/*DUP 


*/ 


35 


D(T13.1). 


/• DUP J(1 V 






.D(T13.1), 


/•DUP_X2 V 






D(T13,1). 


/•DUP2 


V 


40 


D(T13,1), 


/•DUP2_X1 •/ 






D(T13,1). 


rOUP2_X2 V 






D(T13.1). 


/•SWAP 


V 




D(T1 ,1), 


riADD 


•/ 


45 


D(T_ ,1), 








D(T_ .1). 








D(T1 .1), 






50 


D(T_ .1). 


/*ISUB 






D(T. .1). 








D(T_ .1). 






55 


D(T_ .1), 







50 



EP0932865B1 



D(T1 .1). 
D(T„ .1). 

D(T. .1), 
D(T_ .1). 
D(T1 .1), 
D(T_ .1). 
D(T_.1). 
D(T_ .1), 
D(T1 .1). 
D(T_ .1). 
D(T..1), 
D(T_ .1). 
D(T9 .1). 
D(T_ .1). 
D(T_ .1). 
D(T_ .1). 
D(T1 .1). 
D(T_ .1). 
D(T1 .1). 
D(T. .1). 
D(T1 .1), 
D(T. .1), 
D(T1 .1). 

D(T_ .1). 
D(T1 .1). 
D(T_ .1). 
D(T1 .1). 
D(T. .1). 
D(T4 .3). 
D(T_ .1). 
D(T_ .1), 
D(T_ .1). 
D(T. .1). 
D(T_ .1). 
D(T_ .1). 



riMUL 

riDiv 

/•IREM 

/-INEG 

nSHL 
nSHR 
r lUSHR 
/• lAND 

rixoR 
niNC 
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D(T_ ,1). 
D(T_ .1). 
D(T_ .1). 
D(T_ .1). 
D(T_ .1). 
D(T_ .1). 
D(T9 .1). 
D(T9 .1). 
D(T. .1). 
D(T_ .1). 
D(T_ .1). 
D(T. .1). 
D(T_ .1). 
D(T_ .1). 
D(T2 .3), 
D(T2 ,3). 
D(72 .3). 
D(T2 .3). 
D(T2 .3). 
D(T2 .3). 
D(T3 .3). 
D(T3 .3), 
D(T3 .3), 
D(T3 ,3), 
D(T3 .3), 
D(T3 ,3). 
D(T3 .3). 
D(T3 .3). 
D(T4 .3). 
D(T_ .3). 
D(T_ .2). 
D(T2 .0). 
D(T2 .0). 
D(T2 ,1). 
D(T_ .1). 



r INT2BYTE V 
r INT2CHAR V 
/* INT2SH0RT '/ 



r IFEQ 
/* IFNE 
r IFLT 
1* IFGE 
I* IFGT 
r IFLT 

r IFJCMPEQ 
r IFJCMPNE 
r IFJCMPLT 
r IFJCMPGE 
r IFJCMPGT 
/* IFJCMPLE 
/• IF_ACMPEQ 
r IF^ACMPNE 
/•GOTO 
/•JSR 
/•RET 

/•TABLESWITCH ' 
/• LOOKUPSWITCH' 
riRETURN '/ 
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D(T_ .1). 
D(T^ .1). 
D(T8 .1). 
D(T4 .1), 
D(T15,3), 
D(T15,3). 
D(T15.3). 
D(T15,3), 
D(T14.3). 
D(T14.3). 
D(T14.3). 
D(T14.5). 
D(T_ .1). 
D(T11.3). 
D{T16.2). 
D(T_ .3). 
D(T12.1), 
D(TB .1), 
D(T16.3). 
D(T12.3). 
D(T_ .1). 
D(T^ .1). 
D(T^ .1). 
D(T^ .4). 
D(T8 .3). 
D(T8 .3). 
D(T_.5). 
D(T_.5). 
D(T_.1). 
D(T_.1). 
D(T_ .1). 
D(T_ .1). 
D(T„ .1). 
D(T_ .1). 
D(T. ,1). 



/•ARETURN •/ 
/•RETURN V 
/•GETSTATIC •/ 
/•PUTSTATIC •/ 
r GETFIELD V 
r PUTFIELD •/ 
I* INVOKEVIRTUAL V 
r INVOKESPECIAL •/ 
riNVOKESTATICV 
/•INVOKEINTERFACEV 

/* NEW •/ 
/•NEWARRAY V 

/•ARRAYLENGTH V 
rATHROW V 
rCHECKCAST V 
riNSTANCEOF V 



r IFNULL •/ 

r IFNONNULL V 
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D(T. 


. 1 ). 


D(T_ 


. 1 ). 


D(T_ 


, 1 ). 


D(T_ 


. 1 ). 


D(T. 


. 1 ). 


D(T_ 


. 1 ). 


D(T. 


. 1). 




, 1). 


D(T_ 


. 1). 


D(T_ 


. 1). 


D(T_ 


.1). 


D(T_ 


.1). 


P(T_ 


,1). 


D(T_ 


.1). 


D(T. 


.1). 


D(T. 


.1). 


D(T. 


.1). 


D(T_ 


.1). 


D(T_ 


.1). 


D(T_ 


.1). 


D(T_ 


.1). 


D(T_ 


,1 ). 


D(T_ 


.1 ). 


D(T_ 


.1). 


D(T. 


.1). 


D(T_ 


.1). 


D(T_ 


.1). 


D(T_ 


.1). 


D{T, 


,1). 


D(T_ 


.1). 


D(T_ 


.1). 


D(T_ 


.1). 


D(T_ 


.1). 


D(T. 


.1). 




.1). 
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D(T_ .1). 
D(T_ .1). 
D(T. ,1). 
D(T_ .1). 
D(T. ,1), 
D(T_ .1). 
D(T. .1). 
D(T. .1), 
D(T_ .1). 
D(T_ .1), 
D(T. .1 ). 
D(T_ ,1), 



APPENDIX H 

Checks Done On Java Byte Codes By IVP^ 

[0235] Decoding the instruction. This gives us the length to generate the next PC, and the instruction type: 

pcargi = _GETJLENGTH(_decodeinfonnsn]); 
ityp© = _GET_ITYPE(_decodelnfo[insnD: 

[0236] Implement some pre-executlon checks based on this: 
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/* Check the input stack state based on the instuction type */ 
lf(itype <= rrYPE9){ 

if (itype <= ITYPE1) { 
check_stackjnt(1 ); 

} 

check_stack_int(0): 

} 

else If (Itype <=ITYPE12){ 
check_stack_ref(0); 

) 

else if (Itype <ITYPE11){ 
push(1): 



Finally, implement some post execution checks: 



t* Set the output state V 
If (itype <s ITYPE8){ 
If (Itype <=ITYPE8){ 
If (itype >=ITYPE6){ 
pop(1): 

) 



pop(i); 

} 

pop(i): 

) 

else if (itype <= ITYPE10){ 
set_stackjnt(0); 

} 

else if (Itype >= ITYPE1 1 && itype ITYPEIS) { 
set_stack.ref(0); 
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APPENDIX I 

Cheeks Done On Renumbered Java Byte Codes 

[0237] Get the instruction. The numeric value of the Instruction implicitly contains the Instruction type: 

insn = getpc(-1); 
[0238] Implement some pro-execution checks based on this: 



* Check input stack state. By renumbering the byte codes we can 

* perform the necessary security checks by testing if the value of the 

* byte code (and hence the byte code) belongs to the correct group 
V 

if (Insn <=TYPE9_END){ 
if(lnsn<=TYPE1_END){ 
check_stackjnt(1); 

) 

check_stackjnt(0); 

} 

else if (insn <= TYPE12_END) { 
check_stack_ref(0); 

} 

else If (insn <= TYPE1 1_END) { 
push(1) 

) 



[0239] Finally. Implement some post execution checks: 
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* Set output Stack state. 
'/ 

lf{lnsn<aTYPE8_END){ 
if{lnsn <=TYPE6_END){ 
If (Insn >= 7YPE6_START) { 

pop(i): 

} 

pop(1); 

) 

pop(i); 

} 

else If (insn <» 7YPE10_END) { 
S8t_stackjnt(0); 

} 

else If (insn >= TYPEH^START && Insn <= 7YPE16_END) { 
set_stack_ref(0); 

) 
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Reordering of supported Java byte codes by type 

[0240] 

/• TYPE 3 V 

#deflnes_P0P2 0 

#definesJFJCMPEQ 1 

#definesJFJCMPNE 2 

#definesJFJCMPLT 3 

#define sJF_ICMPGE 4 

#define sJF_ICMPGT 5 

#define sJF.ICMPLE 6 

#define sJP-ACMPEQ 7 

#deflnesJF_ACMPNE 8 

/•TYPE 6 7 

#defineTYPE6_START 9 

#def«ne s_SASTORE 9 
#deflne s^AASTORE 10 
#define s.BASTORE 11 

#defineTYPE6_END 12 

/•TYPEIV 



#define sJADD 


13 


#define sJSUB 


14 


#define sJMUL 


15 


#define sJDlV 


16 


#define sJREM 


17 


#definesJSHL 


18 


#define sJSHR 


19 


#definesJUSHR 


20 


#defines lANO 


21 
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#define sJOR 22 
#define sJXOR 23 

#deflne TYPE1_END 23 

rTYPE2V 

#define sJSTORE 24 
#deflne s_POP 25 
#define sJFEQ 26 
#define sJFNE 27 
#deflne sJFLT 28 
#define sJFGE 29 
#define sJFGT 30 
#define sJFLE 31 
#defjne s.TABLESWITCH 32 
#define s_LOOKUPSWrrCH 33 
#define sJRETURN 34 

rTYPE7V 

#define s.SALOAD 35 

#define s.AALOAD 36 

#define s.BALOAD 37 

r TYPE 9 •/ 

#define sJNEG 39 
#define sJNT2BYTE 40 
#define 8JNT2CHAR 41 

#defineTYPE9_END 41 

/•TYPE 8 V 
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#deflne s_ASTORE 42 
#defin8S_ARETURN 43 
#define 8_ATHR0W 44 
#deftne sjFNUU 45 
#define sJFNONNULL 46 

#defin8TYPE8„END 46 
/* TYPE 12 V 

#clefine s_ARRAYLENGTH 47 
#define sJNSTANCEOF 48 

#defineTYPE12_END 48 

/* TYPE 10 V 

#define s^SIPUSH 49 

#define TYPE1 0_END 49 

/•TYPE 5 V 

#define sJLOAD 50 
#define s.ALOAD 51 

/•TYPE 11 V 

#deftneTYPE11„START 52 

#define s_ACONST_NULL 52 
#defrne S.L0C2 53 
#define s.JSR 54 
#defines NEW 55 
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#deflne7YPE11_END 55 
riYPE 16 V 

#define s.NEWARRAY 56 

#defines_CHECKCAST 57 

#define7YPE16_END 57 

/•TYPE 13 V 

#derine s.DUP 58 
#define s_DUP_X1 59 
#define s_DUP_X2 60 

#define s_DUP2 61 
#define s_DUP2_X1 62 
#define sJDUP2_X2 63 

#deflnes_SWAP 64 

rVfPE 14 V 

#define sJNVOKEVIRTUAL 65 r 01000001 V 
#define sJNVOKENONVIRTUAL 66 T 01000010 V 
#define sJNVOKESTATIC 67 r 0100001 1 V 
#define sJNVOKEINTERFACE 68 /* 01000100 V 

/•TYPE 15 V 

#defines_GETSTATIC 69 

#define s_PUTSTATIC 70 

#define s_GETFIELD 71 

#defines_PUTFIELp 72 

/•TYPE4V 
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#defines_NOP 73 

#definesJ)NC 74 
#define s_GOTO 75 

#define s_RET 76 
^defines RETURN 77 



Claims 

1 . '.A microcontroller (10) having a set of resource constraints and comprising: a memory, 

an interpreter (16) loaded in memory and operating within the set of resource constraints, the microcontroller 
(10) characterized by having: 

at least one application loaded in the memory to be Interpreted by the interpreter, wherein the at least one 
application is generated by a programming environment comprising: 

a) a compiler (22) for compiling application source programs (20) in high level language source code fonm 

Into a complied form (24), 

b) a converter (26) for post processing the compiled fomn (24) into a minimized fomi (27) suitable for 
interpretation by the interpreter (16). 

2. The microcontroller (10) of Claim 1, wherein the compiled fomn (24) includes attributes, and the converter (26) 
comprises a means (51 d) for including attributes required by the interpreter (16) while not including the attributes 
not required by the interpreter (16). 

3. The microcontroller (10) of Claims 1 or 2 wherein the compiled form (24) Is In a standard Java class file format 
and the converter (26) accepts as input compiled form (24) in the standard Java class file format and produces 
output (27) in a fonm suitable for interpretation by the interpreter (16). 

4. The microcontroller (1 0) of any of the preceding claims wherein the compiled form (24) includes associating an 
identifying string for objects, classes, fields, or methods, and the converter comprises a means for (57) mapping 
such strings to unique identifiers (51b). 

5. The microcontroller (10) of Claim 4 wherein each unique identifier is an integer. 

6. The microcontroller (1 0) of Claims 4 or 5 wherein the mapping of strings to unique identifiers is stored in a string 
to identifier map file (30, 32). 

7. The microcontroller (10) of any of the preceding claims where in the high level language supports a first set of 
features and a first set of data types and the interpreter (1 6) supports a subset of the first set of features and a 
subset of the first set of data types, and wherein the converter (26) verifies (51c, 52) that the compiled fonn (24) 
only contains features in the subset of the first set of features and only contains data types in the subset of the 
first set of data types. 

8. The microcontroller (10) of Claims 4, 5, 6, or 7 wherein the compiled fomi (24) Is In a byte code fomnat and the 
converter (26) comprises means for translating (54) from the byte codes in the compiled fonm (24) to byte codes 
(27) in a format suitable for interpretation by the interpreter (16) using at least one step in a process including the 
steps: 

a) recording ail jumps and their destinations in the original byte codes (61); 

b) converting specific byte codes Into equivalent generic byte codes or vice-versa (63); 

c) modifying byte code operands from references using identifying strings to references using unique identifiers 
(64); 
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d) renumbering byte codes tn the compiled fomn (24) to equivalent byte codes In the fomiat suitable for Inter- 
pretation (66); and 

e) relinking jumps for which destination address is effected by conversion step b, c, or d (67). 

5 9. The microcontroller (1 0) of any of the preceding claims wherein the application program is compiled into a compiled 
fonm (24) for which the resources required to execute or Interpret the compiled fomn (24) exceed those available 
on the microcontroller. 

10. The microcontroller (10) of any of the preceding claims wherein the conrtpiled fomri (24) is designed for portability 
10 on different computer platfomis. 

11. The microcontroller (10) of any of the preceding claims wherein the interpreter (16) is further configured to deter- 
mine, during the Interpretation of an application, whether an application meets a security criteria selected from a 
set of rules containing at least one rule selected from the set: 

IS 

not allowing the application access to unauthorized portions of memory, 

not allowing the application access to unauthorized microcontroller resources. 

wherein the application is composed of byte codes and checking a plurality of byte codes at least once prior to 
20 execution to verify that execution of the byte codes do not violate a security constraint. 

12. The microcontroller (10) of any of the preceding claims wherein at least one application program Is generated by 
a process including the steps of: 

25 prior to loading the application verifying that the application does not violate any security constraints; and 

loading the application in a secure manner. 

13. The microcontroller (1 0) of Claim 12 wherein the step of loading in a secure manner comprises the step of: 
30 verifying that the loading identity has pemnission to load applications onto the microcontroller. 

14. The microcontroller (10) of Claims 12 or 13 wherein the step of loading in a secure manner comprises the step of: 

encrypting the appltoatlon to be loaded using a loading key. 

35 

15. A method of programming a microcontroller having a memory and a processor operating according to a set of 
resource constraints, the method comprising the steps of: 

inputting an application program (20) in a first programming language; 
40 compiling (22) the application program (20) in the first programming language into a first intennediate code 

(24) associated with the first programming language; 

wherein the first intennediate code (24) being interpretable by at least one first intermediate code virtual 

machine; 

45 wherein the method of programming a microcontroller is characterized by: 

converting (26) the first intermediate code (24) into a second intennediate code (27); 

wherein the second Intermediate code (27) is Interpretable by at least one second intennediate code virtual 
50 machine (16); and 

loading the second intennediate code into the memory of the microcontroller (10). 

16. The method of programming a microcontroller (10) of Claim 15 wherein the step of converting further comprises; 

55 associating an identifying string for objects, classes, fields, or methods and mapping such strings to unique 

identifiers (51b). 

17. The method of Claln^s 15 or 16 wherein the step of mapping comprises the step of mapping strings to integers. 
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18. The method of Claims 15, 16. or 17 wherein the step of converting comprises at least one of the steps of: 

a) recording all jumps and their destinations in the original byte codes (61); 

b) converting specific byte codes into equivalent generic byte codes or vice-versa (63); 

5 c) modifying byte code operands from references using identifying strings to references using unique identifiers 

(64): 

d) renumbering byte codes in the compiled fonnat to equivalent byte codes in the fonnat suitable for interpre- 
tation (66); and 

e) relinking Jumps for which destination address is effected by conversion step a), b), c). d) (67). 

10 

19. The method of any of Claims 1 5 through 1 8 wherein the method is further characterized by wherein the loading 
the second intenmediate code into the memory of the microcontroller further comprises checlcing the second in- 
temnediate code prior to loading the second intemiediate code to verify that the second intemnediate code meets 
a predefined integrity checic and that loading is performed according to a security protocol. 

15 

20. The method of any of Claims 15 through 1 9 wherein the security protocol requires that a particular identity must 
be validated to pennit loading prior to the loading of the second intermediate code. 

21. The method of any of Claims 15 through 20 further characterized by providing a decryption key and wherein the 
20 security protocol requires that the second intemiediate code is encrypted using a loading key corresponding to 

the decryption key. 

22. The microcontroller of any of Claims 1 through 14 further characterized by: 

25 (a) the interpreter being operable to interpret the compiled programs (27) written in a derivative of the inter- 

pretable language wherein a derivative of a program written in the interpretable programming language is 
derived from the program written in the interpretable programming language by applying at least one rule 
selected from a set of mies including; 

30 (1 ) perfomning security checks prior to or during interpretation; 

(2) perfomning structural checks prior to or during interpretation; 

(3) perfonming semantic checks prior to or during interpretation. 

23. The microcontroller (10) of Claim 22 wherein the derivative programs are class files or derivatives of class files. 

35 

24. The microcontroller (1 0) of any Claims 22 or 23 further characterized by: 

the memory containing less than 1 megabyte of storage. 

40 25. The microcontroller (1 0) of any of Claims 22 through 24 wherein the security checks the mk;rocontroller is further 
characterized by: 

(b) logic to receive a request from a requester to access one of a plurality of derivative programs; 

(c) after receipt of the request, detemnine whether the one of a plurality of derivative programs complies with 
4s a predetemiined set of rules; and 

(d) based on the detemiination, selectively grant access to the requester to the one of the plurality of applica- 
tions. 

26. The microcontroller (10) of Claim 25, wherein the predetemnined rules are enforced by the interpreter while the 
so derivative program Is being interpreted by detennining whether the derivative program has access rights to a 

particular part of memory the derivative program is attempting to access. 

27. The microcontroller (10) of any of Claims 22 through 26 further characterized by the microcontroller being con- 
figured to perfomn at least one security check selected from the set having the members: 

55 

(a) enforcing predetemiined security rules while the derivative program Is being interpreted, thereby preventing 
the derivative program from accessing unauthorized portions of memory or other unauthorized mrcrocontroller 
resources. 
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(b) the interpreter being configured to check each bytecode at least once prior to execution to detenmlne that 
the bytecode can be executed in accordance with pre-execution and post-execution checks, 

(c) the derivative program is checked prior to being loaded into the microcontrolier to verify the integrity of the 
derivative progrann and loading Is perfonmed according to a security protocol. 

5 

28. The mk:rocontrolter (10) of Claim 27 wherein the security protocol requires that a particular identity must be vali- 
dated to permit loading a derivative program onto a card. 

29. The microcontroller {1 0) of Claim 27 further characterized by having a decryption key wherein the security protocol 
10 requires that a derivative program to be loaded is encrypted using a toading key corresponding to the decryption 

key. 

30. The microcontroller (10) of any of Claims 22 through 29 further characterized by being configured to provide 
cryptographic services selected from the set including encryption, decryption, signing, signature verifrcation, mutual 

IS authentication, transport keys, and session keys. 

31 . The microcontrolier (1 0) of any of Claims 22 through 30 further characterized by having a file system and being 
configured to provide secure access to the file system through a means selected from the set Including: 

20 (a) the microcontroller having access control lists for authorizing verifying from a file, writing to a file, or deletion 

of a file, 

(b) the microcontroller enforcing key validation to establish the authorized access to a file, and 

(c) the microcontroller verifying card holder identity to establish the authorized access to a file. 

25 32. A computer-program product for a microcontroller (10) having a set of resource constraints and comprising a 
memory and an Interpreter (16) loaded in the memory and operable within the set of resource constraints, the 
computer-program product comprising at least one application which can be loaded in the memory of microcon- 
troller (1 0) and which is to be Interpreted by the interpreter, the application having been generated by a programming 
environment comprising: 

30 

a) a compiler (22) for compiling application source programs (20) in high level language source code fomi Into 
a compiled fomi (24), 

b) a converter (26) for post processing the compiled form (24) Into a minimized fomri (27) suitable for interpre- 
tation by the interpreter (16). 

35 

33. A card comprising a microcontoiler as claimed in claim 1 . 



PatentansprOche 

40 

1. Ein Mikrocontroiler (10) mit einem Set von Ressourcen-Vorgaben und bestehend aus: 

einem Speicher, 

einem im Speicher geladenen Interpreter (16), welcher innerhaib des Sets von Ressourcen-Vorgaben funk- 
45 tionlert, dem Mikrocontroiler (10), dadurch gekennzeichnet, dass er: 

mindestens eine durch den Interpreter zu ubersetzende im Speicher geladene Applikatlon hat, wobei 
mindestens eIne Applikatlon durch eine Programmlerungsumgebung generiert wird, die folgenden Ele- 
menten umfasst: 

50 

a) einem Compiler (22), welcher Anwendungs-Quellprogramme (20) in Queltoodeform hdherer Pro- 
grammiersprache in eine kompilierte Form (24) kompiitert, 

b) einem Konverter (26) zur Umfomriatierung der kompilierten Fonn (24) in eine sich zur Ubersetzung 
durch den Interpreter (16) eignende minimierte Fomri (27). 

55 

2. Mikrocontroiler (10) gemass Patentanspruch 1 . bel welchem die kompilierte Fonm (24) Attribute enthSIt und der 
Konverter (26) cin MIttel (51 d) zur Einfugung der vom Interpreter (1 6) benotigen Attribute, aber nicht zur Einfugung 
der vom Interpreter (16) nicht benotlgten Attribute, umfasst. 
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3. Mikrocontrotler (10) gemass Patentan^ruch 1 Oder 2, be! welchem die kompillerte Form (24) ein standardmdBiges 
Java-Klassendateiformat ist und der Konverter (26) die im standardma3igen Java-K[assendateiformat kompilierte 
Form (24) als Eingabe akzeptiert und die Ausgabe (27) in einer fur die UberseUung durch den Interpreter (16) 
geelgneten Fonm erzeugt. 

4. Mlkrocontroller (10) geniass einem beileblgen vorhergehenden Patentanspruch, bei welchem der kompilierten 
Form (24) eine bezeichnende Zeichenkette (String) fur Objekte. Kiassen, Felder Oder Methoden zugewiesen fst 
und der Konverter ein Mittel enthalt, urn (57) solche Strings in einheitliche Bezetchner (51b) aufzugliedem. 

5. Mlkrocontroller (1 0) gemass Patentanspruch 4, bei welchem jeder einheitliche Bezelchner eine Ganzzahl ist. 

6. Mikrocontrolter (1 0) gemdss Patentanspruch 4 Oder 5, bei welchem die Aufgliederung von Strings in einheitliche 
Bezeichner in einem String zur Map-Date! (30, 32) des Bezeichners gespelchert ist. 

7. Mlkrocontroller (10) gemass einem der vorhergehenden Patentanspruche. bei welchem ein erstes Set von Fea- 
tures und ein erstes Set von Datentypen in hoherer Progranrvniersprache unterstutzt wird und der Interpreter (16) 
ein Subset des Sets von Datentypen unterstutzt und der Konverter (26) Qberpruft (51c, 52), ob die kompilierte 
Form (24) nur Features im Subset des ersten Sets von Features und nur Datentypen im Subset des Sets von 
Datentypen enthSlt. 

8. Mlkrocontroller (1 0) gemass Patentanspruch 4, 5, 6 oder 7, bei welchem die kompilierte Form (24) ein Byte-Code- 
fomiat ist und der Konverter (26) Mittel zur Ubersetzung (54) von Byte-Codes in kompllierter Fonm (24) in Byte-Co- 
des (27) in ein fur die Ubersetzung durch den Interpreter (16) geeignetes Fomnat enthSit, indem mindestens ein 
Schritt aus einem Prozess mit folgenden Schritten gewShIt wird: 

a) Aufzeichnung aller Spriinge und ihr Ziel In den Originai-Byte-Codes (61 ); 

b) Umsetzung spezifischer Byte-Codes in gleichwertlge generische Byte-Codes oder umgekehrt (63); 

c) Venvandiung der Byte-Code-Operanden von Referenzen, welche bezeichnende Strings verwenden, in Re- 
ferenzen, welche einheitliche Bezeichner (64) venvenden; 

d) Neubezifferung von Byte-Codes In kompllierter Form (24) mit gleichwertlgen Byte-Codes in dem fur die 
Ubersetzung (66) geelgneten Fonnat; und 

e) Neuverknupfung der Sprunge, fur welche die Zieladresse Ober den Umsetzungsschritt b, c oder d (67) 
erfolgt. 

9. Mlkrocontroller (10) gemass einem beileblgen vorstehenden Patentanspruch, dadurch gekennzeichnet, dass 
das Appllkationsprogramm In eine kompilierte Fonm (24) kompiliert wird, bei welcher die zur Ausfuhrung oder 
Ubersetzung der kompilierten Form (24) bendtlgten Ressourcen die auf dem Mikrocontroller verfiigbaren Res- 
sourcen uberschreiten. 

10. Mikrocontroller (10) gemass einem beileblgen vorstehenden Patentanspruch, bei welchem die kompilierte Form 
(24) zur Portabilitat auf verschledenen Computer-Plattformen bestlmmt ist. 

11. Mikrocontroller (10) gemass einem beliebigen vorstehenden Patentanspruch, bei welchem der Interpreter (16) 
ferner in einer Weise konfiguriert Ist, dass er wahrend der Ubersetzung einer Anwendung emnlttett, ob eine An- 
wendung den aus einem Set von Regeln gewahlten Sicherheltskriterien gerecht wird mit Hilfe von mindestens 
einer Regel aus dem Set: 

welches der Appllkation den Zugriff auf nicht autorislerte Speichertelle sperrt, 

welches, der Applikation den Zugriff auf nicht autorisieric Mikrocontroller-Ressourcen sperrt. 

wobel die Applikation aus Byte-Codes besteht und eine VIelzahl von Byte-Codes mindestens einmal vor der Aus- 
fuhrung priift, um sicherzustellen, dass die Ausfuhrung der Byte-Codes keine Sicherheitsvorgabe verletzt. 

12. Mikrocontrotler (10) gemass einem beliebigen vorstehenden Patentanspruch. bei webhem mindestens ein Appll- 
kationsprogramm durch einen die folgenden Schritte enthaltenden Prozess erzeugt wird; 

vor dem Laden der Applikation sicherstellen, dass die Applikation keine Sicherheitsvorgaben verietzt, und 
die Applikation auf stehere Weise laden. 
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13. MIkrocontroIIer (10) gemdss Patentanspruch 12, be! welchem der Schritt zum Laden auf slchere Weise folgenden 
Schritt enthalt; 

Oberprufen. ob die Ladeidentitdt zum Laden von Appllkatlonen auf den Mikrocontroller berechtigt ist 

5 

14. Mikrocontroller (10) gemass Patentanspruch 12 Oder 13, bei welchem der Schritt zum Laden auf stchere Weise 
folgenden Schritt enthatt: 

VerschlQsseIn derzu ladenden Appllkatlon anhand eines LadeschlQssels. 

10 

15. Eine Methode zur Programmierung eInes MIkrocontroIlers mit einem Speicher und einem Prozessor, wetehe ge- 
mdss einem Set von Ressourcen-Vorgaben funktionieren, wobei die Methode folgende Schritte umfasst: 

Eingabe eines Applikationsprogramms (20) in einer ersten Programmiersprache; 
'5 Kompilierung (22) des Applikationsprogramms (20) In der ersten Programmiersprache in einen ersten Zwi- 

schencode (24) In Abhangigkeit von der ersten Programmiersprache; 

wobei der erste Zwischencode (24) durch mindestens eine virtuelle Maschine fur den ersten Zwischencode 
interpretierbar ist; 

20 wobei die Methode zur Programmierung eines MIkrocontroIlers dadurch gekennzeichnet ist, dass: 

der erste Zwischencode (24) In einen zweiten Zwischencode (27) umgesetzt (26) wird: 

wobei der zweite Zwischencode (27) durch mindestens eine virtuelle Maschine (16) fur den zweiten Zwi- 
25 schencode interpretierbar ist; und 

Laden des zweiten Zwischencodes In den Speicher des Mikrocontroltets (10). 

16. Methode zur Programmiemng eines Mikrocontrollers (10) gemdss Patentanspmch 15, dadurch gekennzeichnet, 
dass der Umsetzschritt femer folgenden Schritt enthdit: 

30 

Zuweisung einer bezeichnenden Zelchenkette (String) fur Objekte, Klassen, Felder Oder Methoden und Auf- 
gtiederung solcher Strings In einheitliche Bezeichner (51b). 

1 7. Methode gemass Patentanspruch 1 5 oder 1 6, bei welcher der Auf gliederungsschritt den Schritt zur Aufgliederung 
35 von Strings In Ganzzahlen enthalt. 

18. Methode gemass Patentanspruch 15, 16 oder 17, bei welcher der Umsetzungsschritt mindestens einen der fol- 
genden Schritte enthalt: 

^0 a) Aufzeiechnung aller Spriinge und ihrer Ziele in den Origin al-Byte-Codes (61 ): 

b) Umsetzung speziflscher Byte*Codes in gleichwertige generische Byte-Codes oder umgekehrt (63); 

c) Anderung der Byte-Code-Operanden von Referenzen, welche bezeichnende Strings venwenden, In Refe- 
renzen, welche eindeutige Bezetohner (64) venvenden; 

d) Neunummerlerung der Byte-Codes im kompllierten Fomnat In dquivalente Byte-Code Im fur die Obersetzung 
^5 (66) geeigneten Fomriat; und 

e) Neuverknupfung der Sprunge, fiir welche die Zieladresse durch den Umsetzungsschritt a), b), c) oder d) 
(67) ausgefuhrt wird. 

19. Methode gemass Patentanspruch 15 bis 18, welche ferner dadurch gekennzeichnet ist, dass beim Laden des 
so zweiten Zwischencodes in den Speicher des Mikrocontrollers zusitzlich eine PrOf ung des zweiten Zwischencodes, 

bevor er geladen wird, enthalt, urn sicherzustellen, dass der zweite Zwischencode einer vordefinierten IntegrltSts- 
Prufung gerecht wird und dass das Laden gemass dem Sicherheitsprotokoll erfolgt. 

20. Methode gemass Patentanspruch 15 bis 19. dadurch gekennzeichnet, dass eine besondere Identitat bestatigt 
55 werden muss, damit das Laden vor dem Laden des zweiten Zwischencodes mdglich Ist. 

21. Methode gemass Patentanspruch 15 bis 20, welche femer durch die Bereitstellung eines Dechiffrierschiusseis 
gekennzeichnet Ist und wobei das Sicherheitsprotokoll bedlngt, dass der zweite Zwischencode anhand eines dem 
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Dechiffrierschlussel entsprechenden Ladeschlussels verschlusselt wird. 

22. Mikrokontroller gemass jedem beliebigen Patentanspruch 1 bis 14, welcher ferner dadurch gekennzeichnet, 
dass: 

a) der Interpreter ablauffahig zur Ubersetzung des in etner Ableltung der interpretierbaren Sprache des kom- 
pilierten Programms (27) geschrieben ist - wobei eine Ableitung eines in der Interpretierbaren Programnnier- 
sprache geschriebenen Programms vom in der interpretierbaren Programmiersprache geschriebenen Pro- 
gramm abgeleitet ist - Indem mindestens eine aus einem Set Regein gewShlte Regel angewandt wird mit: 

(1) Durchfuhnjng von Sicherheitspriifungen vor Oder wahrend der Ubersetzung: 

(2) Durchfuhrung von strukturellen Prufungen vor oder wahrend der Ubersetzung: 

(3) Durchfuhrung semantischer Prufungen vor oder wahrend der Ubersetzung. 

23. MIkrocontroller (10) gemSss Patentanspruch 22, bei welchem die abgeleiteten Programme Klassendateten oder 
Abieitungen von Klassendateien sind. 

24. I\^ikrocontroiler (1 0) gemass jedem beliebigen Patentanspruch 22 oder 23, welcher femer dadurch gekennzeich- 
net ist, dass der Spetoherinhalt kteiner als 1 Megabyte ist. 

25. MIkrocontroller (10) gemass jedem beliebigen Patentanspruch 22 bis 24. bei welchem Srcherheitsprufungen des 
MIkrocontrollers ferner folgende Merkmale autwelsen: 

(b) Loglkteil fOr den Empfang einer Anforderung von einem Anforderer fOr den Zugrlff auf eine VIeizahl abge- 
leiteter Programme; 

(c) Ermittlung - nach dem Empfang der Anforderung - ob eines aus der Vielzahl abgeleiteten Programme mit 
einem vordefinierten Set von Regein ubereinstimmt; und 

(d) auf der Basis der Emiittlung dem Anforderer einen selektiven Zugrlff zu einer Applikation aus der Vielzahl 
zu gewdhren. 

26. MIkrocontroller (10) gemSss Patentanspruch 25, bei welchem die vordefinierten Regein durch den Interpreter wdh- 
rend der Ubersetzung des abgeleiteten Programms durchgesetzt werden durch Emiittlung. ob das abgeleitete 
Programm die Zugriffsberechtigung zu einem besonderen Speicherteil hat, auf welchen das abgeleitete Programm 
zuzugreifen versucht. 

27. MIkrocontroller (1 0) gemSss jedem beliebigen Patentanspruch 22 bis 26, welcher ferner dadurch gekennzeichnet 
ist, dass der Mikrocontrolter zur Durchfuhrung von mindestens einer aus dem Set von Mitgliedem gewdhlten 
SicherheitsprOfung konfigurlert Ist: 

a) Durchsetzung der vordefinierten Sicherheitsregelen, wahrend das abgeleitete Programm ubersetzt wird, 
wodurch dem abgeleiteten Programm der Zugrlff auf nicht autorisierte Speicherteile oder nk:ht autoristerte 
MIkrocontroller- Ressourcen gespeni wird. 

b) Konfigurierung des Interpreters in einer Weise, dass jeder Byte-Code mindestens elnmai vor der Ausfuhrung 
gepruft wird, um zu emiittein, ob der Byte-Code In Ubereinstimmung mit Prufungen vor und nach der Ausfuh- 
rung ausgefuhrt werden kann. 

c) Prufung des abgeleiteten Programms vor dem Laden in den MIkrocontroller, um seine Integritat und das 
Laden in Ubereinstimmung mit einem Sicherheitsprotokoll sicherzustellen. 

28. MIkrocontroller (10) gemass Patentanspruch 27, bei welchem das Sicherheitsprotokoll die Bestatigung einer be- 
sonderen Identitat vorschreibt, um das Laden eines abgeleiteten Programms auf eine Karte zu enmoglichen. 

29. MIkrocontroller (10) gemass Patentanspruch 27, welcher ferner durch das Vorhandensein eines Dechiffrierschius- 
sels gekennzeichnet Ist, wobei das Sicherheitsprotokoll vorschreibt, dass ein zu ladendes abgeleitetes Programm 
anhand eines dem Dechiffrierschlussel entsprechenden ladeschlussels zu laden ist. 

30. MIkrocontroller (10) gemass jedem beliebigen Patentanspruch 22 bis 29, des weiteren dadurch gekennzeichnet, 
dass er zur Beistellung von Verschlusselungs-services, wetche aus dem die Chiffrierung. Dechiffrierung, Unter- 
schrift, SignaturprCff ung, gegenseltige Authentlfizterung, den TransportschlQssel und Sitzungsschliissel enthaiten- 
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den Set gewahlt wurden, konfiguriert [st. 

31. Mikrocontroller (10) gemass jedem beliebigen Patentanspruch 22 bis 30, des weiteren durch ein Dateisystem 
gekennzeichnet, watches zur Beistedung eines slcheren Zugriffs auf das Dateisystem Ober ein bus dem Set ge- 

5 wahlten Mittel konfiguriert ist, bestehend aus: 

a) denn Mikrocontroller, welcher Zugriff auf Kontroil-Usten zur Berechtigung zum Lesen ab einer Datei, Schrel* 

ben auf eine Datei, Losciien einer Datei hat, 

b) dem Mikrocontroller, welcher die Sehlussetfreigabe zum Aufbau der Zugangsberechtigung zu einer Datei 
10 durchsetzt, und 

c) dem Mikrokontroller zur Oberprufung der Kartentrdgerldentitdt zum Aufbau der Zugangsberechtigung zu 
einer Datei. 

32. Ein Computer-Programmprodukt fur einen Mikrocontroller (10) mit einem Set von Ressourcen-Vorgaben und mit 
IS einem Spek^her und einem im Speicher geladenen Interpreter (1 6), welcher innerhalb des Sets von Ressourcen- 

Vorgaben lauffahig ist, wobei das Computer-Programmprodukt mindestens eine vom Interpreter zu ubersetzende 
in den Speicher des Mikrocontrollers (10) ladbare Applikation umfasst, wobei die Apptikation von einer Program- 
mierumgebung erzeugt wurde, die folgenden Elementen umfasst: 

20 a) einem Compiler (22), welcher Anwendungs-Quellprogramme (20) in Quellcodefomi hoherer Programmier- 

sprache in eine kompiiierte Form (24) kompiliert. 

b) einem Konverter (26) zur Umfomnatierung der kompilierten Fomn (24) in eine sbh zur Obersetzung durch 
den Interpreter (16) eignende minimlerte Form (27). 

25 33. Eine Karte die einen Mikrocontroller gemass Patentanspruch 1 umfasst. 



Revendlcatfons 

30 1 . Microcontrdleur (10) poss6dant un ensemble de contraintes de ressources et comprenant : 
une m^moire, 

un interpr^teur (16) charg6 dans la mSmoire et fonctionnant k Tint^rieur de I'ensemble de contraintes de res- 
sources, le microcontrdleur (10) 6tant caracterlse en ce qu'il comprend : 

35 

au moins une application charg^e dans la m^moire devant Stre tnterprdtde par I'interpr^teur, dans lequel 
ladite au moins une application est produite par un environnement de programmation comprenant : 

a) un compilateur (22) destine k compiler des programmes d'application sources (20) sous une forme 
^0 de code source k langage 6volu6 en une fonne compilde (24), 

b) un convertisseur (26) destine k r^aliser un post-traitement de la forme compilde (24) en une forme 
r^duite (27) adapt^e pour i'interpr^tation par i'interpr^teur (16). 

2. Microcontrdleur (10) selon la revendication 1, dans lequel la fomne compil6e (24) comprend des attributs, et le 
45 convertisseur (26) comprend un moyen (51 d) permettant d'inclure des attributs requis par I'interpr^teur (16) tout 

en n'incluant pas les attributs non requis par Tinterprdteur (16). 

3. Microcontrdleur (10) selon les revendications 1 ou 2, dans lequel la forme compil^e (24) est dans un format de 
fichier de classe Java standard et le convertisseur (26) accepte en tant qu'entr^e ia forme complice (24) dans le 

50 fonnat de fichier de classe Java standard et produit une sortie (27) sous une fonne adapt^e pour TinterprStation 

par i'interpr^teur (16). 

4. Microcontrdleur (10) selon I'une quelconque des revendications pr^^dentes dans lequel la fonne complice (24) 
comprend {'association d'une chaTne d'identificatlon pour des objets, des classes, des champs ou des procdd^s, 

55 et le convertisseur comprend un moyen (57) permettant de mapper lesdites chaTnes k des identif Icateurs uniques 
(51b). 

5. Microcontrdleur (10) selon la revendication 4, dans lequel chaque identif k;ateur unique est un nombre entier. 
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6. Mtcrocontroleur (10) seton [es revendlcations 4 ou 5, dans lequel le mappage de chaTnes k des fdentificateurs 
uniques est stocks dans un fichier de mappage de chafnes d des identificateurs (30, 32). 

7. Microcontrdleur (10) selon Cune quelconque des revendlcations pr6c6dentes dans lequel le langage 6volu6 sup- 
5 porte un premier ensemble de fonctionnaIit6s et un premier ensemble de types de donn6es et Tinterprdteur (16) 

supporte un sous-ensemble du premier ensemble de fonctionnalit6s el un sous-ensemble du premier ensemble 
de types de donn^es, et dans (equel le convertlsseur (26) v^rifie (51c, 52) que la fomne compiI6e (24) contient 
uniquement des fonctionnallt6s du sous-ensemble du premier ensemble de fonctionnalit6s et contient uniquement 
des types de donn6es du sous-ensemble du premier ensemble de types de donndes. 

10 

8. Microcontrdleur (10) selon les revendlcations 4, 5, 6 ou 7 dans lequel la forme compiI§e (24) est dans un fomiat 
de code octet (byte code) et (e convertlsseur (26) comprend des moyens penmettant de traduire (54) k partir des 
codes octet dans la fomie compilde (24) en des codes octet (27) dans un fomiat adapts pour t'interpr^tation par 
I'interpr^teur (16) en utilisant au moins une 6tape d'un proc6d6 comprenant les stapes consistent k : 

15 

a) enregistrer tous les sauts et leurs destinations dans les codes octet d'origlne (61) : 

b) convertir certains codes octet sp6ciflques en des codes octet g6n6riques Equivalents ou vice-versa (63) : 

c) modifier des op6randes du code octet & partir de r6f6rences utilisant des chafnes d'identification en des 
r6f6rences utilisant des Identificateurs uniques (64) : 

20 d) renumEroter les codes octet dans la forme complice (24) en des codes octet Equivalents dans le format 

adapte pour I'lnterprEtation (66) ; et 

e) rEenchainer les sauts pour lesquels I'adresse de destination est obtenue par I'Etape de conversion b, c ou 

d (67). 

25 9. Microcontroleur (10) selon I'une quelconque des revendlcations prEcEdentes dans lequel le programme d'appli- 
catlon est compllE en une fontie compilEe (24) pour laquelle les ressources requlses afin d*exEcuter ou d'interprEter 
la fomne compilEe (24) dEpassent celles disponibles sur le microcontrdleur. 

10. Microcontrdleur (10) selon I'une quelconque des revendicatlons prEcddentes dans lequel la fomie compilEe (24) 
30 est congue pour pouvotr etre transfEr§e sur differentes plates-fonnes informatiques. 

1 1 . Microcontrdleur (1 0) selon I'une quelconque des revendlcations prEcEdentes dans lequel TinterprEteur (1 6) est en 
outre configure de manlEre d determiner, pendant I'interprEtation d'une application, si une application rEpond k 
des critEres de sEcuritE sElectionnEs k partir d'un ensemble de regies contenant au moins une rkg\e sElectionnEe 

35 panmi I'ensemble : 

ne pas autoriser I'accEs de I'application k des parties non autorisEes de la mEmoire, 

ne pas autoriser I'accEs de rappllcation k des ressources non autorisEes du microcontrdleur, 

40 dans lequel Tapplication est composEe de codes octet (byte codes) et en vErifiant une pluraiitE de codes 

octet au moins une fois avant I'exEcution afin de verifier que I'exEcution des codes octet ne viole pas une contrainte 
de sEcuritE. 

12. Microcontrdleur (1 0) selon Tune quelconque des revendlcations prdcEdentes dans lequel au moins un programme 
45 d'application est prodult par un procEdE comprenant les Etapes consistent k : 

verifier avant le chargement de I'application que {'application ne viole aucune contrainte de sEcuritd ; et 
charger I'application de manlEre sEcurisEe. 

so 13. Microcontrdleur (1 0) selon la revendication 1 2, dans lequel I'Etape de chargement de manlEre sEcurisEe comprend 
Tetape consistent k : 

verifier que I'identitE rEalisant le chargement est autorisEe k chai^er des applications sur le microcontrdleur. 

S5 14. Microcontrdleur (1 0) seton les revendlcations 12 ou 13, dans lequel I'Etape de chargement de manidre sEcurisEe 
comprend I'Etape consistant k : 

chiffrer I'application devant dtre chargEe en utilisant une cl6 de chargement. 
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15. Proc^dd de programmatlon d'un mtcrocontr6Ieur possddant une m^moire et un processeur fonctionnant selon un 
ensemble de contraintes de ressources, le proc^d6 comprenant les stapes consistant k : 

introduire un programme d'application (20) dans un premier langage de programmatlon ; 
5 compiler (22) le programme d'application (20) dans le premier langage de programmatlon en un premier code 

fntennSdlaire (24) associd au premier langage de programmatlon ; 

dans (equel le premier code (nterm6diaire (24) est interpr^table par au moins une machine virtuelle k premier 
code intenti^diaire ; 

10 dans lequel le proc6d6 de programmatlon d*un microcontrdleur est caracterise par : 

la conversion (26) du premier code interm^diaire (24) en un second code lntemft§diaire (27) ; 

dans lequel le second code intemnSdiaire (27) est interpr^tabte par au moins une machine virtuelle k second 
'5 code Intemn^diaire (1 6); et 

k charger le second code intenn^diaire dans la mSmoire du microcontrdleur (10). 

16. Proc^dd de programmatlon d'un microcontrdleur (10) selon la revendication 15 dans lequel T^tape de conversion 
comprend en outre : 

20 

I'association d'une chaTne d'identification pour des objets, des classes, des champs ou des proc6d§s, et le 
mappage de ces chaTnes k des identificateurs uniques (51b). 

1 7. Proc6d6 selon les revendicattons 1 5 ou 1 6 dans lequel I'dtape de mappage comprend I'^tape consistant k mapper 
25 des chaTnes k des nombres entiers. 

18. Proc6d6 selon les revendicatlons 15, 16 ou 17 dans lequel I'^tape de conversion comprend au moins I'une des 
6tapes consistant k : 

30 a) enregistrer tous les sauts et leurs destinations dans les codes octet (byte codes) d'origine (61) ; 

b) convertir certains codes octet sp6ciflques en des codes octet g6n6rlques Equivalents ou vice-versa (63) ; 

c) modifier des opErandes du code octet k partir de r^f^rences utilisant des chaTnes d'identification en des 
r^f^rences utilisant des identificateurs uniques (64) : 

d) renum^roter les codes octet dans le format compile en des codes octet Equivalents dans ie format adapts 
35 pour rinterpr6tation (66) ; et 

c) rEenchaTner les sauts pour lesquels I'adresse de destination est obtenue par I'Etape de conversion a), b), 
c) ou d) (67). 

19. ProcEdE selon Tune quelconque des revendicatlons 15^18 dans lequel le procEdd est en outre caracterise en 
40 ce que le chargement du second code intemn^dialre dans la m§moire du microcontrdleur comprend en outre la 

verification du second code IntermEdialre avant le chargement du second code intermEdlaire afin de verifier que 
le second code IntemnEdiaIre rEpond k un contrdle d'intEgrltE prEdEfini et que le chargement est rEalisE confor- 
mEment k un protocole de sEcuritE. 

45 20. Procddd selon I'une quelconque des revendicatlons 15^19 dans lequel le protocole de sEcuritE exige qu'une 
identity partlculiere soit impErativement validEe pour pennettre le chargement avant le chargement du second 
code IntennEdialre. 

21. ProcedE selon Tune quelconque des revendicatlons 15 ^ 20 caracterise en outre par la fournlture d'une clE de 
so dEchiffrement et dans lequel le protocole de sEcuritE exige que le second code intemiEdialre soit chiffrE k I'aide 

d'une clE de chargement correspondant k la c\6 de dEchiff rement. 

22. Microcontrdleur selon Tune quelconque des revendicatlons 1^14 caracterlsE en outre en ce que : 

S5 (a) I'interprEteur est utilisable pour interpreter les programmes compiles (27) Merits dans une d4riv6e du lan- 

gage Interpr6table dans lequel une d6riv6e d'un programme 6crit dans le langage de programmatlon InterprE- 
table est dErivEe du programme Ecrit dans le langage de programmatlon interprEtable en appllquant au moins 
une rdgle sElectlonnEe k partir d'un ensemble de rdgles comprenant : 
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(1) la realisation de contrdtes de sdcurit6 avant ou pendant rinterpr^tatlon : 

(2) la realisation de controles structurels avant ou pendant Tinterprdtation ; 

(3) la realisation de centrales semantiques avant ou pendant Tinterpretation. 

5 23. Microcontrdleur (10) selon la revendication 22, dans lequel (es progrannmes derives sont des fichters de classe 
ou des derivees de fichfers de ciasse. 

24. Microcontrdleur (10) selon I'une des revendlcations 22 ou 23, caracterlse en outre en ce que : 
10 la memoire contient moins de 1 mega-octet de stockage. 

25. Microcontrdleur (10) selon Tune quelconque des revendications 22 k 24, dans lequel la routine de securite qui 
verifle le microcontrdleur est en outre caracterlsee par : 

15 (b) une logique devant recevoir une demande provenant d'un demandeur pour acceder k i'un parmi une plu- 

ralite de programmes derives : 

(c) aprds reception de la demande, le fait de detemniner si t'un pamni une pluralite de programmes derives se 
confonne k un ensemble de regies predeterminees ; et 

(d) en fonction de la detemiination, accorder de manifere selective I'acces du demandeur k Tune pamnl la 
20 pluralite d'applications. 

26. Microcontrdleur (10) selon la revendication 25, dans lequel les regies predeterminees sont appliquees par i'inter- 
preteur pendant que le programme derive est en cours d'intetpretation en detenninant si le programme derive a 
des droits d'acces k une partie donnee de la memoire k laquelle le programme derive tente d'acceder. 

25 

27. Microcontrdleur (10) selon I'une quelconque des revendications 22 k 26, caracterlse en outre en ce que le mi- 
crocontrdleur est configure de manidre k accomplir au moins un contrdle de securite selectlonne panni i'ensemble 
compose des elements : 

30 (a) appliquer des regies de securite predeterminees pendant que le programme derive est en cours d'inter- 

pretation, en empdchant ainsi le programme derive d'acceder k des parties non autorlsees de memoire ou k 
d'autres ressources non autorisees du microcontrdleur. 

(b) i'tnterpreteur etant configure de manidre k verifier chaque code octet (byte code) au moins une fois avant 
{'execution afin de detenminer que le code octet peut dtre execute confomiement k des verifications avant et 

35 aprfes execution. 

(c) le programme derive est verifie avant d'etre charge dans le microcontrdleur afin de verifier I'integrite du 
programme derive et le chargement est realise conformement k un protocole de securite. 

28. Microcontrdleur (10) selon la revendication 27, dans lequel le protocole de securite exige qu'une identite donnee 
40 soit validee pour permettre le chargement d'un programme d6riv6 sur une carte. 

29. Microcontrdleur (10) selon la revendication 27, caracterlse en outre en ce qu'il possede une cl6 de dechiffrement 
dans lequel le protocole de securite exige qu'un programme derive devant dtre charge soit chiffre k I'aide d'une 
cie de chargement correspondant k \a cie de dechiffrement. 

45 

30. Microcontrdleur (10) selon i'une quelconque des revendications 22 k 29. caracterise en outre en ce qu'il est 
configure de maniere k fournir des services de chiffrement seiectionnes panni I'ensemble comprenant le chiffre- 
ment, le dechiffrement, la signature, la verification de signature, I'authentificatlon mutuelle, les cies de transport 
et les cies de session. 

50 

31. Microcontrdleur (10) selon I'une quelconque des revendications 22 k 30, caracterlse on outre en ce qu'il possdde 
un systeme de fichiers et qu'il est configure de maniere k fournir un acces securise au systeme de fichiers par le 
bials d'un moyen seiectionne parmI I'ensemble comprenant : 

^5 (a) la possession par le microcontrdleur de listes de contrdle d'accds pour autoriser la lecture k partir d'un 

fichier, I'ecriture dans un fichier ou la suppression d'un flchier, 

(b) rappltcatton par le microcontrdleur d'une vaiidation de cie afin d'etablir I'acces autorise k un fichier. et 

(c) la verification par le microcontrdleur de lldentite du titutaire de la carte afin d'etablir I'acces autorise k un 
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fichier, 

32. Produit de programme informatique pour un microcontrdleur (10) poss^dant un ensemble de contraintes de res- 
sources et comprenant une m^molre et un interpr^teur (16) charge dans la m^moire et utillsable k rintSrieur de 

5 ('ensemble de contraintes de ressources, le produit de programme Infomnatique comprenant au moins une appli- 

cation qui peut §tre charg^e dans la m^moire du microcontrdleur (10) et qui doit dtre tnterpr^t^e par t'interpr6teur, 
i'application ayant 6X6 produite par un environnement de programmation comprenant : 

a) un compilateur (22) destin6 ^ compiler des programmes d'application sources (20) dans un code source h 
10 langage 6volu6 en une forme complice (24), 

b) un convertisseur (26) destine k r^aliser un post^traitement de la forme compjI§e (24) en une fomne r6duite 
(27) adaptde pour {'interpretation par I'interpr^teur (16). 

33. Une carte comprenant un microcontrdleur selon la revendication 1 . 

15 
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